ru.cisco

 
 - RU.CISCO ---------------------------------------------------------------------
 From : Vladimir Kravchenko                  2:5020/400     27 Jun 2003  12:38:57
 To : All
 Subject : call-id / conf-id и тп
 -------------------------------------------------------------------------------- 
 

 
 Вообщем решение проблемы сопосталения answer и originate звонков мы таки
 нашли. Для начала повторяю проблему:
 Киска в радиус аккаунтинге VoIP звонков предусмотрела единственный
 идентификатор для сопоставления asnwer звонка с originate звонками, этот
 идентификатор h323-conf-id и является идентификатором H.323 стека. В H.323
 стеке есть два явных идентификатора, это conferenceID и callIdentifier, эти
 идентификаторы сохраняются на всем пути VoIP звонка.
 Сразу оговорим полезность такого идентификатора - если иметь оба этих
 идентификатора в журнале звонков, то можно сопоставить звонки на на разных
 железках, можно сопоставить звонок на шлюзе со звонком на гейткипере и тп.
 
 Теперь о проблеме парсинга кискиного радиуса:
 Предположим что "источник" звонка имеет алгоритм рераутинга звонков при
 неудачном соединении (например, cisco hunt), в этом случае "источник" звонка
 может иметь два направления терминации (два диалпира) указывающие на один и
 тот же терминирующий шлюз, на нашу киску радиус с которой мы собираем. При
 рераутинге звонка H.323 стек не пересобирается, то есть по всех
 оригиниционный звонках "источника" будут одни и те же conferenceID и
 callIdentifier, исходя из того что h323-conf-id == conferenceID в
 аккаунтинге принимающего шлюза мы получим следующее (s-id это Acct-Session-Id)
 
 answer start s-id=1 conf-id=1
   originate start s-id=2 conf-id=1
   originate stop s-id=2 conf-id=1
   originate start s-id=3 conf-id=1
   originate stop s-id=3 conf-id=1
 answer stop s-id=1 conf-id=1
 answer start s-id=4 conf-id=1
   originate start s-id=5 conf-id=1
   originate stop s-id=5 conf-id=1
 answer stop s-id=4 conf-id=1
 
 Все совершенно предскажуемо - два входящих звонка вызваных рераутингом на
 звонящем оборудовании, один и тот же h323-conf-id так как пересбора H.323
 никто не производил. Ежику понятно что все радиусовские сообщения
 перемешаются, это же рераутинг, звноки нулевые и отказы как правило
 вылетают очень быстро, к тому же радиус сервер засовывает события в RDBMS
 как правило через пул соединений, тут вообще уже работа транзакций
 непредсказуема.
 Да, собственно формулировка вопроса: надо воссоздать полную картинку
 звонка.
 
 Решение:
 Hадо добавить идентификатор который бы характеризовал каждое дерево
 answer-originate в не замисимости от сигнализационного h323-conf-id. В
 качестве источника такого идентификатора возьмем [infotag get aaa_new_guid].
 Далее, на incoming voip dial-peer включаем отложенный аккаунтинг через
 voice-class, пишем TCL приложение которое делает следующее
 1) генерит новый guid
 2) генерит старт аккаунтинга на leg_incoming записывая новый giud в одно из
 доступных VSA, мы выбрали h323-prompt-id
 3) создаем callInfo выставляя в качестве giud новый guid и сохраняем старый
 с incomingGuid
 4) завем leg setup передавая наш callInfo
 
 Таким образом требуемый нам идентификатор внутренней конференции быдет в
 h323-prompt-id answer части звонка и в h323-conf-id originate части
 звонка.
 
 Спасибо за внимание :)
 -- 
 Vladimir Kravchenko / PK Mostcom JSC / system engineer
 Tel: +7 095 2312255 / UIN: 132038843 / Email: jimson@mostcom.ru 
 --- ifmail v.2.15dev5
  * Origin: Demos online service (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор