|
ru.cisco
- RU.CISCO ---------------------------------------------------------------------
From : German Myzovsky 2:5020/400 14 Apr 2002 07:41:19
To : "Dmitry V. Golov"
Subject : Re: Идентификация партнера по Answer VoIP
--------------------------------------------------------------------------------
> Один из известных мне выходов - заставить этого партнера делать все вызовы
> от его шлюзов на мой шлюз через (и от имени) его h323-proxy. Hо я очень
> сомневаюсь, что этот партнер на это пойдет и не уверен, есть ли у него
> вообще h323-proxy.
Чем шире сеть, тем накладнее проксить RTP, и тем меньше шансов,
что на выходе будет стоять h323-proxy. Максимум, что можно ожидать -
если gatekeeper вашего партнера сделает ACF.callModel.gatekeeperRouted
вместо ACF.callModel.direct. TCP можно будет открыть только для GK.
UDP придется открыть для всех.
В этом случае вы получите в _эккаунтинг-пакетах_ правильный адрес GK
начиная с Cisco IOS версии 12.2(5) и выше, включая ветку ED.
Если схема gatekeeperRouted + RADIUS accounting вас устраивает,
дальше можете не читать.
С авторизацией хуже. Самое правильное - открыть TCP для всех, а
контроль доступа поручить RADIUS'у. Это проще, чем синхронизация ACL.
Мы как раз эксплуатируем развитую сеть шлюзов, пропуская все исходящие
звонки через (и от имени) H.323 GK, то есть с одного адреса (gatekeeperRouted).
Hо RTP не проксируем принципиально.
Так вот, если Setup _не_ содержит fastStart, принимающий Cisco/RADIUS
видит адрес GK и успешно его авторизует. Если же используется fastStart,
то приходит адрес (sic!) абстрактного вызывающего шлюза/терминала.
Авторизация не проходит. Значит идентификация партнера через
Cisco TCL IVR API зависит от позиции h323 call start [fast|slow]
у этого самого партнера. Весело, правда?
Хорошо, думаю, надо порыться в TCL API, благо там не все документировано.
В примере app_remote_ip_authenticate.2.0.0.tcl для получения адреса
партнера используется leg_remoteipaddress. В документации про этот
параметр - ни слова. Раззиповал IOS, сделал
"strings C5300-JS.BIN | grep ^leg_",
нашел еще пяток недокументированных параметров, но все не то.
Hаконец, если проанализировать debug voip ccapi inout, получается,
что в TCL IVR попадает значение переменной accountNumber.
Разное для fastStart и slowStart.
Поскольку отказ от fastStart унизителен, остается схема
gatekeeperRouted + ACL. Hе забудьте закрыть 5060/udp и 5060/tcp,
у голосовых Cisco неотключаемый sip-ua.
> Кто нить может подсказать, какие есть еще возможности идентифицировать этого
> партнера, не зная заранее адресов его шлюзов, а зная только адрес его
> гейткипера?
Вообще-то GK должен общаться с другим GK через LRQ. Если вы готовы
к такому повороту, изучите GKTMP и, самое главное, узнайте какой
GK у партнера. Если самодельный или Cisco IOS - хорошо.
Если generic H.323-compatible - плохо. Потому что в стандартной структуре
LRQ нет идентификатора звонка, а значит нет никакой связи между
запросом от GK и последующим Setup'ом от шлюза. GK от Cisco передает
нужный идентификатор в LRQ.nonStandardData, значит есть шанс прировнять
LRQ к ARQ и корректно авторизовать звонок. Hо про accounting
через RADIUS можно забыть.
--
Герман.
--- ifmail v.2.15dev5
* Origin: Tario.NET (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
