Коллеги, кно-нибудь занимался подобной ...?

Чего, собственно, хочется добиться?

Необходимо, связать Cisco GK и NRS. Чтобы запросы LRQ проходили и всё работало.

что бы что работало?

Есть NRS, на нём зарегистрирован Cs1000 с телефонами. Есть Cisco GK, на нём зарегистрирован цисковский шлюз с телефонами. Необходимо сделать звонок с цтсковского шлюза на CS1000 и обратно.

Рекомендую почитать NTP "IP Peer Networking Installation and Configuration" (553-3001-213) там есть раздем по увязыванию между собой двух GK.
В доке описан вариант с GK от sucession 3.0 и NRS 4/4.5, но суть от этого не меняется - делается через collaborative servers.

SergSH пишет
Рекомендую почитать NTP "IP Peer Networking Installation and Configuration" (553-3001-213) там есть раздем по увязыванию между собой двух GK.
В доке описан вариант с GK от sucession 3.0 и NRS 4/4.5, но суть от этого не меняется - делается через collaborative servers.

Разумеется.
Схема выглядит следующим образом:

Сокращения С-Cisco, N-Nortel



N_Phone------CS1000S-------NRS-------------------------C_GK------------C_CallManager------C_Phone



C_GK прописан в NRS как Collaboration Sever. Делаем звонок с N_Phone на C_Phone. CS1000S шлёт запрос ARQ на NRS. Этот номер неизвестен системе, NRS пересылает этот запрос в виде LRQ на C_GK, при этом в запросе номер вызываемого абонента стоит в поле partyNumber. Это поле не воспринимается Cisco GK, так как он использует поле e164. Аналогично, когда приходит LRQ запрос на NRS от Cisco GK, то номер стоит в поле e164. NRS перенаправляет этот запрос в виде ARQ на CS1000S и теперь уже он не понимает циску, так как ждёт запрос в поле partynumber.



В документации IP Peer Networking(553-3001-213), на стр. 264 написано(Note 5), что NRS поддерживает e164, но совершенно непонятно как это настраевается.



Вопросы:

Есть ли способ заставить CS1000S понимать запрос с полем e164??
Если ответ “нет”, то есть ли способ заставить NRS подменять поля с e164 на partynumber и наоборот?
Если ответ “нет”, то есть ли другие способы?

Из CS в SS вызов уходит, конечно же, с NPI E.164, вы это проверили ?

jetc пишет
Из CS в SS вызов уходит, конечно же, с NPI E.164, вы это проверили ?

NPI и TON - это поля в запросе ISDN Setup. С этим проблем нет. Засада в полях протокола RAS. Конкретно - поля, в которых обозначен вызываемый номер абонента.

Вот результат моих последних исследований:
1. Nortel NRS не воспринемает запросы LRQ в формате e164
2. Nortel NRS нормально воспринемает запросы ARQ в формате e164 и пересылает их далее в виде LRQ в том же формате.
2. Cisco GK не воспринемает запросы partyNumber

Я правильно понял первый пункт как то, что вы это проверили ? Лог трассировки соответствующего вызова по соотв. D-каналу и лог с GK не могли бы показать ?

jetc пишет
Я правильно понял первый пункт как то, что вы это проверили ? Лог трассировки соответствующего вызова по соотв. D-каналу и лог с GK не могли бы показать ?

ммм...
а смысл? я же расписал где грабли лежат!

вот запрос LRQ с NRS на Cisco GK:
1d00h: RAS INCOMING PDU ::=
value RasMessage ::= locationRequest :
{
requestSeqNum 53793
destinationInfo
{
partyNumber : privateNumber :
{
privateTypeOfNumber localNumber : NULL
privateNumberDigits "9339"
}
}
replyAddress ipAddress :
{
ip '0AC87323'H
port 1719
}
sourceInfo
{
h323-ID : {"SFOGK"},
url-ID : "h.323:SFOGK;phone-context=SibFO.com@SibF..."
}
canMapAlias TRUE
}

+++++++++++++++++++++++++++++++++++++++++++++
а вот чего он ждёт:
1d01h: RAS INCOMING PDU ::=

value RasMessage ::= locationRequest :
{
requestSeqNum 1085
destinationInfo
{
e164 : "9501"
}
nonStandardData
{
nonStandardIdentifier h221NonStandard :
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
data '8284901100805905E5B115C11D1F000000C0A877...'H
}
replyAddress ipAddress :
{
ip '0A041236'H
port 1719
}
sourceInfo
{
h323-ID : {"PFOGK"}
}
canMapAlias TRUE
}

И лог этого вызова из D-канала, пожалуйста.