Уважаемые дамы и господа! Для вас сохранен старый форум по адресу http://forum.intersyst.ru

Страницы: 1 2 След.
RSS
SIP Trunk Group: Правило занятия каналов VoIP плат
 
Доброго времени суток всем,
Имеется OXE с 3-мя платами INTIP2 и более 20-ти удалённых выносов MG. Вчера заметил что на на одном из MG выдало ошибку что не хватает кодеков. Запустил compvisu и увидел на этом MG что несколько каналов стоит в состоянии CG (RTP Direct : CG = Comp used:Flux RTP on GW). Я так понял что центральная станция воспользовалась кодеками платы GD этого MG для звонка на железку, подключенную по SIP. В этот момент на 3-ёх платах INTIP2 центральной станции было много свободных каналов.
Какой же принцип занятия каналов SIP TG? Как заставить брать каналы только из плат INTIP2?
MG и центральная станции в разных IP-доменах.
 
Происходящее совпадает с правилами, опсанными в документе "Resource Allocation in an IP Distributed Architecture", входящем в системную документацию ?
 
Не совпадает. По этим правилам кодеки я должен брать в первую очередь из своего IPMG (или кристалла)-что в принципе логично. У меня не так.
 
В каком смысле "из своего" ?
Каков сценарий вызова, каково разделение станции на домены, в каком домене упомянутый MG, в каком домене SIP ex. gw ?
 
"cвой" означает тот MG, где находится абонент (при исходящей связи) или ТГ (при входящей)
У Дарта Вейдера в столе всякого навалено: карты разные галактик и портрет Гагарина.
 
Цитата
Dmitry Ryzhakov пишет:
"cвой" означает тот MG, где находится абонент (при исходящей связи) или ТГ (при входящей)

Это прекрасно.

Но внимание, вопрос: в каком MG находится SIP TG ?
Дополнительный вопрос: в каком MG находится IP абонент ?
 
SIP TG находится в процессорном кристалле 0, там же где и 3 платы INTIP2.
Про IP абонента речь не шла. К кристаллу 0 через SIP TG приключена железка (колл-центр стороннего производителя например)
 
То-ли вы вопросы невнимательно прочитали, то-ли считаете, что вам виднее.
Ну если вам виднее, то сами себе и ответьте, почему так происходит, зачем на форуме спрашивать.
Раз у вас "SIP TG в 0 кристалле", а данные о сценарии вызова и IP доменах - секретные.
 
Мне казалось, что SIP TG не привязывается к какому-либо кристаллу. А использует свободные ресурсы. Может, у вас все доступы во всех INTIP привязаны к каким-либо IP TG? Тогда они будут заниматься далеко не в первую очередь.
 
Правильно, SIP TG не привязывается к железу но привязывается к своему домену. Соответственно и должна пользоваться как мне кажется и как описано в доках ресурсами своего домена, т.е. в моём случае ресурсами 3-ёх плат INTIP2. У меня так не происходит.
 
Вы бы лучше вместо слова "свой" указали конкретные цифры - 0,1, и т.д. Так как, например, домен номер 0 имеет особое значение. В каком домене SIP TG и платы INTIP кристалла 0? И повторю вопрос: все доступы (Access) во всех INTIP привязаны к каким-либо IP TG?
и сценарий, конечно, неизвестен.
 
Как SIP TG привязывается к своему домену (и тем более шелфу)? Под SIP TG в данном случае - вы имеете в виду SIP gateway? SIP TG? Или платы VoIP (которые вы не указывали в менеджменте ни SIP TG, ни SIP gateway).

Мне кажется для начала - прописать домены и удаленные ресурсы рассавать в них.

Может быть побаловаться с System/ other system/ system param. - Mutual aid with remote ACT
 
У меня 3 платы INTIP2. 2 из них находятся в разных TG для организации H.323 стыка с OXO. Одна из плат нигде в транкгруппах не прописана. Все платы находятся в домене 0 (смотрю в Ethernet parameters конкретной платы).
Под SIP TG я понимаю SIP trunk group.
Mutual aid with remote ACT: 0 : No Mutual aid: no mutual aid possible with remote ACT
Изменено: Prost - 17.09.2013 18:25:37
 
SIP TG - но там кроме ентити и нода - ничего больше нет, конкретное железо там не прописано. Поэтому нельзя сказать, что она в 0-м шелфе.
 
Но ведь 3 платы INTIP2 находятся в 0 шелфе и привязаны к домену 0. Соответственно и абоненты 0 шелфа должны ходить через свой домен 0 и соответственно свои доменные платы INTIP2 или я ошибаюсь?
Страницы: 1 2 След.
Читают тему