Итак имеется 61С rel 4.5. На которой в данный момент работают h323 транки. Пытаюсь поднять SIP транки.
1. Создал рут, D-канал прописал такой же как и у h323 рута.
2. Создал транки
3. Прописал настройки в SIP GW settings и Signaling Server properties (в элемент манагере)
В итоге не могу зарегить сигнальник как Gateway Endpoint в NRS. В логах выдает ошибку:
20/08/2010 18:55:13 LOG0003 tSPReg: spRegistrar (line 695): endpoint [YYY] not configured
Но что интересно, входящий звонок по SIP проходит на ура.

Если пытаюсь сделать исходящий звонок по SIP, то получаю в логах:
20/08/2010 18:38:21 LOG0006 SIPNPM: -> INVITE sip:8801@YYY;transport=tcp;user=phone SIP/2.0
20/08/2010 18:38:21 LOG0006 SIPNPM: -> From: <sip:4524@YYY;user=phone>;tag=a001eac-13c4-4c6ecb9d-9692877-51f2

т.е. почему то NRS (NRS ли?) кидает исходящий звонок обратно на Meridian
В настройках Signaling Server properties YYY это Sip domain name и Sip endpoint name.

И на последок еще один вопрос - если я поднимаю одновременно и SIP и H323, то я должен зарегить меридиан как gateway endpoint два раза, по SIP и по H323???

D-канал используется один и тот же для H.323 и SIP. Ноду зарегистрировать на NRS два раза, как H.323 endpoint и как SIP endpoint. А кстати, с чем стыкуешь по SIP?

Вот чет нода по sip и не региться(

С Астериском колдую... у меня вообще смешная ситуация получилась. По h323 удалось настроить звонки с мерина на астер, в другую сторону тупо не улетают с астера. Решил плюнуть и попробовать по sip. В итоге с полпинка завелись звонки уже с астера на мерин, а вот с меридиана на астер пока никак... но тут мне кажется, что то все таки в настройках мерина или НРС неправильно прописываю и звонки неправильно маршрутизируются.

Выложи сюда скриншоты блока SIP GW из element manager'а и endpoint из NRS. Будем посмотреть :)

Ну вот собсвтвенно настройки
Для SIP я создал в НРС отдельный домен. Кстати, не может ли быть конфликт, если имя домена совпадает с имением sip gateway endpoint?

Ну вот собсвтвенно настройки
Для SIP я создал в НРС отдельный домен. Кстати, не может ли быть конфликт, если имя домена совпадает с имением sip gateway endpoint?

В настройках сигнальника имя эндпойнта MCBSIP, а в NRS почему-то MKBSIP :confused:, да еще и совпадает с именем домена.

Да, да, виноват, недосмотрел. Теперь станция в НРС нормально зарегистрировалась.

Но к сожалению все равно не проходит звонок Meridian->Aster
Маршрутизацию на Асетр прописал статическим SIP адресом
на сигнальнике дал
oam> SIPCallTrace on on
oam> SIPTraceLevel 1
в логах видно

From: <sip:4524@MKBSIP;user=phone>;tag=a001eac-13c4-4c7263cd-1773c740-221c
23/08/2010 12:04:30 LOG0006 SIPNPM: -> To: <sip:8801@MKBSIP;user=phone>;tag=1716

т.е. немного непонятно, кидает ли нрс в итоге на нужный адрес номер 8801? SIP тест в нрс проходит нормально, но меня смущает что на * в консоли ничего не видно, а если бы шли какие то запросы с мерина то что то бы я точно видел.

Немного непонятно, где остальные логи вызова, в которых видно или не видно, что говорит NRS и т.д.

Вот полный лог вызова с 4524(Мерин)-8801(Астер)

oam> 23/08/2010 12:32:27 LOG0006 SIPNPM: SIPCallTrace: 23/8/10 12:32:27 Send chid:91 ip:172.30.0.11:5060 SIP method INVITE(0)

23/08/2010 12:32:27 LOG0006 SIPNPM: -> INVITE sip:8801@MKBSIP;transport=tcp;user=phone SIP/2.0
23/08/2010 12:32:27 LOG0006 SIPNPM: -> From: <sip:4524@MKBSIP;user=phone>;tag=a001eac-13c4-4c726a5b-178d61be-6ef
23/08/2010 12:32:27 LOG0006 SIPNPM: -> To: <sip:8801@MKBSIP;user=phone>
23/08/2010 12:32:27 LOG0006 SIPNPM: -> Call-ID: f4298c4-a001eac-13c4-4c726a5b-178d61be-14c9@MKBSIP
23/08/2010 12:32:27 LOG0006 SIPNPM: -> CSeq: 1 INVITE
23/08/2010 12:32:27 LOG0006 SIPNPM: -> Via: SIP/2.0/TCP 172.30.0.10:5060;branch=z9hG4bK-4c726a5b-178d61be-75fc
23/08/2010 12:32:27 LOG0006 SIPNPM: -> Supported: 100rel,sipvc,replaces,timer
23/08/2010 12:32:27 LOG0006 SIPNPM: -> User-Agent: Nortel CS1000 SIP GW release_4.5 version_sse-4.50.88
23/08/2010 12:32:27 LOG0006 SIPNPM: -> P-Asserted-Identity: <sip:4524@MKBSIP;user=phone>
23/08/2010 12:32:27 LOG0006 SIPNPM: -> Privacy: none
23/08/2010 12:32:27 LOG0006 SIPNPM: -> x-nt-e164-clid: +4524@MKBSIP;user=phone
23/08/2010 12:32:27 LOG0006 SIPNPM: -> History-Info: <sip:8801@MKBSIP;transport=tcp;user=phone>;index=1
23/08/2010 12:32:27 LOG0006 SIPNPM: -> x-nt-corr-id: 0000005d0c201a1708@00c08b0a3bba-c8954712
23/08/2010 12:32:27 LOG0006 SIPNPM: -> Contact: <sip:4524@MKBSIP:5060;maddr=172.30.0.10;transport=t cp;user=phone>
23/08/2010 12:32:27 LOG0006 SIPNPM: -> Allow: INVITE,ACK,BYE,REGISTER,REFER,NOTIFY,CANCEL,PRACK, OPTIONS,INFO,SUBSCRIBE,UPDATE
23/08/2010 12:32:27 LOG0006 SIPNPM: -> Content-Type: multipart/mixed ;boundary=unique-boundary-1
23/08/2010 12:32:27 LOG0006 SIPNPM: -> Content-Length: 675
23/08/2010 12:32:27 LOG0006 SIPNPM: ->
23/08/2010 12:32:27 LOG0006 SIPNPM: -> --unique-boundary-1
23/08/2010 12:32:27 LOG0006 SIPNPM: -> Content-Type: application/SDP
23/08/2010 12:32:27 LOG0006 SIPNPM: ->
23/08/2010 12:32:27 LOG0006 SIPNPM: -> v=0
23/08/2010 12:32:27 LOG0006 SIPNPM: -> o=- 133 1 IN IP4 172.30.0.10
23/08/2010 12:32:27 LOG0006 SIPNPM: -> s=-
23/08/2010 12:32:27 LOG0006 SIPNPM: -> t=0 0
23/08/2010 12:32:27 LOG0006 SIPNPM: -> m=audio 5200 RTP/AVP 0 8 18 4
23/08/2010 12:32:27 LOG0006 SIPNPM: -> c=IN IP4 172.30.2.59
23/08/2010 12:32:27 LOG0006 SIPNPM: -> a=fmtp:18 annexb=no
23/08/2010 12:32:27 LOG0006 SIPNPM: -> a=fmtp:4 bitrate=5.3
23/08/2010 12:32:27 LOG0006 SIPNPM: -> a=sendrecv
23/08/2010 12:32:27 LOG0006 SIPNPM: ->
23/08/2010 12:32:27 LOG0006 SIPNPM: -> --unique-boundary-1
23/08/2010 12:32:27 LOG0006 SIPNPM: -> Content-Type: application/x-nt-mcdn-frag-hex ;version=sse-4.50.88 ;base=x2611
23/08/2010 12:32:27 LOG0006 SIPNPM: -> Content-Disposition: signal ;handling=optional
23/08/2010 12:32:27 LOG0006 SIPNPM: ->
23/08/2010 12:32:27 LOG0006 SIPNPM: -> 0500db01
23/08/2010 12:32:27 LOG0006 SIPNPM: -> 0107130081900000a2
23/08/2010 12:32:27 LOG0006 SIPNPM: -> 09090f00e9a0830001005b
23/08/2010 12:32:27 LOG0006 SIPNPM: -> 1315070011fa0f00a10d02010102020100cc040000aa1b
23/08/2010 12:32:27 LOG0006 SIPNPM: -> 1e0403008183
23/08/2010 12:32:27 LOG0006 SIPNPM: -> --unique-boundary-1
23/08/2010 12:32:27 LOG0006 SIPNPM: -> Content-Type: application/x-nt-epid-frag-hex ;version=sse-4.50.88 ;base=x2611
23/08/2010 12:32:27 LOG0006 SIPNPM: -> Content-Disposition: signal ;handling=optional
23/08/2010 12:32:27 LOG0006 SIPNPM: ->
23/08/2010 12:32:27 LOG0006 SIPNPM: -> 011201
23/08/2010 12:32:27 LOG0006 SIPNPM: -> 00:0e:0c:d7:b1:48
23/08/2010 12:32:27 LOG0006 SIPNPM: -> --unique-boundary-1--
23/08/2010 12:32:28 LOG0006 SIPNPM: SIPCallTrace: 23/8/10 12:32:28 Recv chid:91 ip:172.30.0.10:5060 SIP response 404

23/08/2010 12:32:28 LOG0006 SIPNPM: -> SIP/2.0 404 Not Found
23/08/2010 12:32:28 LOG0006 SIPNPM: -> From: <sip:4524@MKBSIP;user=phone>;tag=a001eac-13c4-4c726a5b-178d61be-6ef
23/08/2010 12:32:28 LOG0006 SIPNPM: -> To: <sip:8801@MKBSIP;user=phone>;tag=47915
23/08/2010 12:32:28 LOG0006 SIPNPM: -> Call-ID: f4298c4-a001eac-13c4-4c726a5b-178d61be-14c9@MKBSIP
23/08/2010 12:32:28 LOG0006 SIPNPM: -> CSeq: 1 INVITE
23/08/2010 12:32:28 LOG0006 SIPNPM: -> Via: SIP/2.0/TCP 172.30.0.10:5060;received=172.30.0.10;branch=z9hG4 bK-4c726a5b-178d61be-75fc
23/08/2010 12:32:28 LOG0006 SIPNPM: -> Contact: <sip:4524@MKBSIP:5060;maddr=172.30.0.10;transport=t cp;user=phone>
23/08/2010 12:32:28 LOG0006 SIPNPM: -> Content-Length: 0
23/08/2010 12:32:28 LOG0006 SIPNPM: ->
23/08/2010 12:32:28 LOG0006 SIPNPM: ->
23/08/2010 12:32:28 LOG0006 SIPNPM: SIPCallTrace: 23/8/10 12:32:28 Send chid:91 ip:172.30.0.11:5060 SIP method ACK(1)

23/08/2010 12:32:28 LOG0006 SIPNPM: -> ACK sip:8801@MKBSIP;transport=tcp;user=phone SIP/2.0
23/08/2010 12:32:28 LOG0006 SIPNPM: -> From: <sip:4524@MKBSIP;user=phone>;tag=a001eac-13c4-4c726a5b-178d61be-6ef
23/08/2010 12:32:28 LOG0006 SIPNPM: -> To: <sip:8801@MKBSIP;user=phone>;tag=47915
23/08/2010 12:32:28 LOG0006 SIPNPM: -> Call-ID: f4298c4-a001eac-13c4-4c726a5b-178d61be-14c9@MKBSIP
23/08/2010 12:32:28 LOG0006 SIPNPM: -> CSeq: 1 ACK
23/08/2010 12:32:28 LOG0006 SIPNPM: -> Via: SIP/2.0/TCP 172.30.0.10:5060;branch=z9hG4bK-4c726a5b-178d61be-75fc
23/08/2010 12:32:28 LOG0006 SIPNPM: -> Contact: <sip:4524@MKBSIP:5060;maddr=172.30.0.10;transport=t cp;user=phone>
23/08/2010 12:32:28 LOG0006 SIPNPM: -> User-Agent: Nortel CS1000 SIP GW release_4.5 version_sse-4.50.88
23/08/2010 12:32:28 LOG0006 SIPNPM: -> x-nt-corr-id: 0000005d0c201a1708@00c08b0a3bba-c8954712
23/08/2010 12:32:28 LOG0006 SIPNPM: -> Allow: INVITE,ACK,BYE,REGISTER,REFER,NOTIFY,CANCEL,PRACK, OPTIONS,INFO,SUBSCRIBE,UPDATE
23/08/2010 12:32:28 LOG0006 SIPNPM: -> Content-Length: 0

Из приведенного куска трейса
а) понятно, что удаленная сторона сказала 404 Not found
б) непонятно, кем была удаленная сторона

Это весь трейс ? Если да, то неверно настроен рутинг вызовов на NRS.

Да весь лог.
Не очень понятно как может быть неправильно настроена маршрутизация, если в нрс/sip routing test все проходит =\

Не очень понятно, почему вы считаете, что данные, которые вы вводите в routing test, совпадают с тем, что приходит от вашей АТС (в результате ваших настроек).

Сделайте трассировку этого вызова в D-канале.

А также предъявите ваши SIP URI Map и Routing entries.

C D-каналом этим, засада. Он уже был давно запрограммирован, и не мной.
По командам enl msgi/msgo выводит всю информацию в HEXe:

DCH 10 IMSG REL COMP REF 00008183 TN 00009C02 CH 00000003 CK 2F4F9B60
DCH 10 I 2F4F9B60
2F 0A 00 05 08 02 01 83 0B
i
DCH 10 IMSG DISC REF 000001C0 TN 00008DC3 CH 00000040 CK 2F4FA3D4
DCH 10 I 2F4FA3D4
2F 0A 00 09 08 02 81 C0 07 02 02 81 90

первый раз такое вижу, и не знаю пока как это вылечить.

Ууу, как все запущено.
Документацию на PRI Maintenance почитали бы, что-ли, или хотя бы описание оверлея, в котором вы enl msgi/msgo делаете,на предмет команд set msgi/ set msgo.

Ну как то не приходилось работать с уровнями D канала выше 0го. Но спасибо за наводку.

В итоге действительно получил

DCH 10 OMSG SETUP REF 000001DB CH 144 0 0 3 TOD 13:41:27
FEAT :CRID
FEAT :CDS
FEAT :NCID
PROGRESS: ORIG ADDR IS NOT ISDN
CALLING #:4524 NUM PLAN: E164/SUBSCRIBER (NXX)/LOCL
CALLED #:8801 NUM PLAN: E164/SUBSCRIBER (NXX)/LOCL

DCH 10 IMSG CALLPROC REF 000001DB CH 144 0 0 3 TOD 13:41:27

DCH 10 IMSG DISC REF 000001DB CH 144 0 0 3 TOD 13:41:27
CAUSE :NO ROUTE TO DESTINATION

DCH 10 OMSG RELEASE REF 000001DB CH 144 0 0 3 TOD 13:41:27

DCH 10 IMSG REL COMP REF 000001DB CH 144 0 0 3 TOD 13:41:27





В настройках SIP не силен, вроде дела все по доке, вот скриншоты.


в роутинге решил не заморачивваться и прописать все доступные варианты

В настройках sip gw не прописан uri map для E164/SUBSCRIBER

Прописал в Element manger E164/SUBSCRIBER - PublicSubscriber
все равно в D канале no route to destination

Прописал в Element manger E164/SUBSCRIBER - PublicSubscriber
все равно в D канале no route to destination

PublicSubscriber - из головы взяли?
Не верно, uri map должен соответствовать тому что в nrs.

Прописал +7495
и ЗАРАБОТАЛО!!
Теперь звонки ходят в обе стороны. Всем ОГРОМНОЕ спасибо. Надо бы мне повдумчевее почитать про все эти доменные имена.