Добрый день.
Я понимаю, что эта тема опять 25, но у меня ни в какую не получается принять вызов на нужном STA.
Станция lik300. SIP транк с оператором по которому идут входящие на конкретный номер.
Имеется регистрация под UID 6 (PGM126) c такими настройками:
Нажмите для просмотра прикрепленного файла
Настроена CO5 на регистрацию под UID6 (PGM133) и выделена в группу 6 (PGM140):
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла

Регистрация проходит успешно Registered.
Далее настраиваю приём входящих на CO5 по номеру MSN Table (PGM202) с конкретного номера -> на индекс 10 в PGM231:
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла

Делаю звонок, вызов приходит и падает на CO5, но далее не коммутируется на заданный индекс 10 - STA 1077.

Пробовал включать ICLID Table Usage ON и прописывал в ICLID Ring Assignment(204) маршрут, но он тоже не работает.

Пробовал в CO/IP Ring Assignment(144) для CO5 прописывать STA 1077, не работает.

В итоге вызов уходит по непонятному мне маршруту не туда куда нужно.

Снял трассировку, где вот что вижу (реальные данные логина/номеров заменил на текст типа login/from_num/to_num):

113364154-[Sim_SipCheckIPForIPAuthen] Trunk match from_ip(sip.callkeeper.ru), via_ip(100.101.102.103)
113364154-[Sipm_SipTransportMsgReceivedExt]..method(INVITE)..
113364154-[Sipm_SipEvCallCreate] SIPCO Call
113364154-
[[[[[[[[[[@@@@@ [SIPM] Creation Call ID => 126 (0)@@@@@]]]]]]]]]]
113364154-
[[[[[[[[[[@@@@@ [SIPM] Creation Call SS ID => 127 @@@@@]]]]]]]]]]
113364154-[CallIdx:126(All:200)][Sipm_SipCallCreate](max:3 OUT:0,IN:1)
113364154-[CallIdx:126][Sipm_SipEvCallCreate] INCOMMING call was created
113364154-[CallIdx:126][Sipm_SipEvCallMsgReceive] SIPM <--- INVITE
113364154-[CallIdx:126][Sipm_SipConnProcInviteInd] reqUriAddr(login)
113364154-[CallIdx:126][Sipm_SipConnProcInviteInd] fromUser(from_num)
113364154-[CallIdx:126][Sipm_SipConnProcInviteInd] toUser(to_num)
113364156-[CallIdx:126][Sipm_SipConnProcInviteInd] rcvdestAddr(to_num)
113364156-[CallIdx:126][Sipm_SipConnProcInviteInd] destAddr(to_num)
113364156-[CallIdx:126][Sipm_SipConnProcInviteInd] rcvsrcAddr(from_num)
113364156-[CallIdx:126][Sipm_SipConnProcInviteInd] Trunk Call(no entry in table)
113364156-[Sipm_SipGetTrunkRouteNoSub] match(via:100.101.102.103)
113364156-[CallIdx:126][Sipm_SipConnProcInviteInd] route:2
113364156-[GetColFromSIPProvider] (col:5) Get from Idle(First)
113364156-[Sipm_SipUtilGetOtherHeaderInMsg] Alert-Info => NULL
113364156-[CallIdx:126][Sipm_SipConnProcInviteInd] proxyIp(100.101.102.103), contactIP(100.101.102.103)
113364156-[CallIdx:126][Sipm_SipConnProcInviteInd] toIP(sip.callkeeper.ru), viaIP(100.101.102.103)
113364156-[CallIdx:126][Sipm_SipConnProcInviteInd] fromIp(sip.callkeeper.ru), fromUser(from_num)
113364156-[CallIdx:126][Sipm_SipConnProcInviteInd] Caller's origin Display Name : ["from_num"]
113364156-[CallIdx:126][Sipm_SipConnProcInviteInd] Caller's Display Name : [from_num]
113364156-[Sipm_SipUtilGetOtherHeaderInMsg] P-Asserted-Identity => NULL
113364156-[Sipm_SipUtilGetOtherHeaderInMsg] Privacy => NULL
113364156-[Sipm_SipUtilGetOtherHeaderInMsg] Remote-Party-ID => "from_num" <sip:from_num@sip.callkeeper.ru>;party=calling;screen=yes;privacy=off
113364156-[Sipm_SipUtilGetOtherHeaderInMsg] MS-CALL-SOURCE => NULL
113364156-[Sipm_SipUtilGetOtherHeaderInMsg] Diversion => <sip:to_num@192.168.1.15>;reason=unconditional
113364156-[CallIdx:126][Sipm_SipConnProcInviteInd] INVITE Ind(S:from_num<from_num@100.101.102.103>, D:to_num)
113364156-[Sipm_SipUtilGetOtherHeaderInMsg] Supported => timer
113364156-[Sipm_SipCheckReplaceSupport] replaces is not supported
113364156-SDP Msg Construct Parse - SinglePart
113364156-=============================================

Если желаете настраивать приём входящих по номеру MSN Table (PGM202), то в 126-й программе укажите для Ring Route Type значение MSN-DID CONVERSION(PGM145). А в 145-й программе для DID Conversation Type значение Use "as is" (no treatment).

Спасибо за ваш ответ. Сделал как вы посоветовали:
В PGM126:
Нажмите для просмотра прикрепленного файла
PGM145:
Нажмите для просмотра прикрепленного файла

Теперь при звонке 2 гудка, потом служебное сообщение LIK "Неправильно набран номер", затем вызов уходит на группу, прописанную в PGM144:
Нажмите для просмотра прикрепленного файла

Видимо MSN не отрабатывает и вызов уходит на маршрут, прописанный для СО5 в PGM144.
Хотя по сигнализации номер toUser в точности соответствует номеру, прописанному в MSN Called Telephone Number для CO Line Range 5-5.
Теперь вопрос, почему не работает MSN Table?

Попробуйте PGM 126 Ring Route Type - DID Conversion

У меня так и было изначально (писал в первом посте) при этом: "В итоге вызов уходит по непонятному мне маршруту не туда куда нужно".

Я правильно понимаю, Вы хотите, чтоб при входящем звонке, на номер например 84991234567, с номера 89067654321, звонок направлялся на нужного абонента?

Не важно с какого номера, но важно на какой номер.
Если ко мне вызов приходит на мой городской номер 84991234567, который живет у меня в SIP на линии СО5, то конкретно этот вызов отправлять на указанный STA или HUNT. Если на номер 84957654321, то на другой HUNT.

У меня так
PGM 126
Ring Route Type - DID Conversion
DID Conversion Type - Modifify Using Flexible DID Conversion Table
PGM 145
DID Conversion Type - Use "as is" (no treatment)
PGM 231
Для Index 567
Day Ring Mode Destination - STA 1000
Night Ring Mode Destination - STA 1000
Name - 1234567
При такой настройке, у меня при звонке из вне, на номер 4951234567, попадает на абонента 1000 (это для примера)
Единственное, у меня нет привязки к определенной CO. Но думаю, это мелочь, главное добиться желаемого.

У меня работает именно так.

В 126 проге DID Conversion Type надо указать DID Digit Conversion!

А какие значения у вас в PGM143?

Не изменилось: "Неправильно набран номер" и тд

CO/IP GROUP - нужная мне группа
CO VoIP Mode - COMMON
DISA CO Access - OFF
Остальное как у Вас

А CO Type у CO5 DID?

По SIP у вас только CO5?

Я имел в виду тут ISDN CO Line Attr(143,151)

Если верить, скринам, то скорей всего, да.

Нет, есть ещё один транк на другой СО, но там норм отрабатывает. При идентичных настройках на СО5 не работает почему-то. Так и не смог понять почему.

Приложите свой скрин этих настроек

Уверены, что вызовы поступают именно по CO 5? Точнее, только по CO 5?

Да, увидел, что DID.

Да, даже по трассировке это видно.

Получилось?

Нажмите для просмотра прикрепленного файла

Нет. Это я ответил на вопрос про уверенность, что у меня только по СО5 этот вызов поступает.

А в целом, попробовали по моим настройкам?

у меня
COLP Table Index и CLIP Table Index - N/A
Station CLI Type - Station CLI 1
DID Remove Number - 0

Действительно, непонятно. У меня проблем нет, как у меня я писал.
В PGM 126 у меня так:
Нажмите для просмотра прикрепленного файла

Настройки, конечно, надо не по скринам смотреть, а по бекапу. В комплексе, таки сказать...

Номер, получаемый в invite, совпадает с учеткой?

Вот настройки второго сип подключения на СО6 при которых вызов нормально коммутируется по MSN на VSF6.
При аналогичных настройках СО5 не работает.

Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла

Учетка не по номеру, а по текстовому логину

А по CO 6?

Нажмите для просмотра прикрепленного файла
Может это \поможет вам разобраться...

Попробуйте сделать инициализацию, предварительно сделав бекап. Залить бекап. Потом снова попробуйте настроить по своему.
Мне пару раз помогло.

Это у меня перед глазами распечатанное лежит и в первую очередь на это ориентировался.
Правильно ли я понимаю из этого алгоритма, что при Ring Route Type: DID Conversion, из приходящего номера удаляются
International Access Code/My Area Code/My Area Prefix Code (как участвует DID Remove Number?), далее входящие номер трансформируется в PGM126 согласно полю DID Conversion Type. Если там указано DID Digit Conversion, то номер трансформируется до 3-значного числа по шаблону полей ниже:
12 Number of Digits (2-4) Expected from DID Circuit: 3
13 DID Digit Mask (4 digits: *,#,0-9): #***

А что далее? Что есть DID Ring Destination после PGM126 и PGM145? Ведь после всех преобразований получится номер, который не соответствует ни одному из наших STA.

Тоже по логину, а не по номеру. Тогда получается по алгоритму имею зеленый маршрут?
Нажмите для просмотра прикрепленного файла

MSN почему-то не отрабатывает и вызов уходит на CO/IP Ring Assignment(144). Почему?
Так что ясности эта схема не внесла, а еще больше запутала

Вы мой вариант пробовали? Как я настраивал.

Да, конечно. При первом же вашем совете сделал как у вас. Вызов улетел по непонятному мне маршруту.

Можете мне прислать свой бекап, ТОЛЬКО предварительно, убрав оттуда, все свои регистрационные данные, SIP, номера, пароли, если есть таковые. Хочу попробовать с Вашим бекапом потестировать.

Нет, сделаю сейчас по другому.... Посмотрите ЛС от меня

Коль у вас учетка не по номеру, а по текстовому логину, то все это не актуально!
По идее, согласно  Incoming_SIP_trunk_algorithm.ppt, полученный DID должен проверяться PGM 202...

Как бы, да.


Согласно DID/DISA Destination(167)

Таки, ДА, зеленый маршрут. Я только что проверил вариант учетки по логину. И да, настройки PGM 126 в этом варианте никаким боком.
Вопрос, почему это не работает у вас? На ум пока приходит только одно - в MSN прописан не тот номер, который приходит в INVITE в поле To.

Тогда согласно алгоритму и моему зеленому маршруту приходим на 202, где MSN почему-то не отрабатывается, хотя номер приходит ровно тот, что я прописал в Called Telephone Number для CO Line Range 5-5. Я его скопировал прямо из трейса из полей toUser и destAddr. Пробовал задать все СО, а не только 5-5, но тоже не работает. Глюк?
Следующим шагом, согласно алгоритму должна быть ветка Not Matched -> PGM143 -> PGM145 -> DID Ring Destination.
DID Ring Destination = DID/DISA Destination(167) ?
Почему в моем случае сообщение "Неправильный номер" и далее PGM144 по СО5?

Не знает АТС куда направить вызов, вот и отрабатывает 167-я прога для ошибки.

У меня отрабатывает 144, а не 167.

Ох, оно, в итоге то, может и 144-я отрабатывает, если в 167-й для Error указано Attendant (Ring Assign) и для CO вызовы в 144-й назначены. Не вижу противоречий!
Но, 167-я первичнее!