|
ru.cisco
- RU.CISCO ---------------------------------------------------------------------
From : Vladimir Kravchenko 2:5020/400 10 Jun 2003 10:40:46
To : Igor Blagodetelev
Subject : Re: parsing radius voip
--------------------------------------------------------------------------------
>>>>> "IB" == Igor Blagodetelev writes:
VK> Результат: 4 call leg в radius accounitng с одинаковым h323-conf-id.
VK> Вопрос: Hа основании какой мат модели можно сопоставить answer с
VK> originate что бы получились корректные _два_ звонка - с PSTN на GK и с
VK> GK в PSTN ?
IB> После долгих ночей занятий йогой и вкуривания дыма от распечатанного
IB> труда индийских инженеров вот тут:
ужасть...
IB> В каждом Start пакете есть h323-setup-time. Stop пакеты более
IB> информативны и более интересны для разбора, там встречаются IP адреса,
IB> setup time, connect time и disconnect time, h323-voice-quality
IB> (величина в общем-то показывающая общий уровень цен на дрова с
IB> о. Мадагаскар) и кое-какую информацию об IP трафике.
Hе знаю как там дрова, а вот ICPIF вроде как стандарт IETF. Впрочем может я
и гоню.
У меня вопрос чего ты курил и куда нечеловеческие усилия прилагал? Про
Start/Stop, call-origin и прочие я на старости лет и так знаю. Вопрос был
про то так собственно сопоставить соответствующие call legs.
Originate Telephone запросто может быть отнесен к answer Telephone, имеет
на то полное право. Более того, каждый из этих двух звоноков может быть на
много сложнее - с несколькими originate "внутри" каждого answer.
Вот у меня только два варианта алгоритма вырисовываются
1) Сопоставление по acct-session-id на основании того что данный счетчик
инкрементный и полагая что ни одна originate сессия не может получить
session-id больше "своей" answer части. Ключевой информацией для разделения
легов на два звонка в данном случае служит наличие второго
answer. Реализация этого алгоритма пи...
2) Есть такой очень странный атрибут subscriber, все что написанно в
документации это то что это какая то ботва из CAS/R2 сигнализации. Hет у
меня CAS, есть только PRI, бедные мы. Судя по моему detail, если звонок
приперся с PSTN то все его леги будут иметь subscriber=RegularLine, если же
пришел с VOIP то subscriber=Unknown. Если положится на это поле то можно
опять вернутся к более или менее простому алгоритму с уникальным ключем
каждой конференции, только ключем этим будет h323-conf-id + subscriber.
Вот я собственно пошел по второму пути, но все равно вляпался.
answer1 start
originate1 start
originate1 stop
answer2 start
answer1 stop
originate2 start
originate2 stop
answer2 stop
Парсеру извините достаточно сложно объяснить что ты типа погоди, хер его
знает где аккаунтинг подержи и дождись запоздавшего стопа. А без него
"закрыть" звонок тоже никак не получится.
Как такой звонок получился? А элементарно, кипер терминировал звонок,
получил отказ из PSTN (originate), через алгоритм рероутинга он обнаружил
что надо терминировать звонок через ту же самую кошку (с другим префиксом
например) и звонок опять приперся.
P.S. я все таки никак не могу понять, за каким хером киска использует
стандартизованное поле H.323 сигнализации для идентификации своих
"внутренних" конференций, ведь они никакого отнонения к h323 конференциям
они не имеют, ну вот слабо было свой атрибут добавить ?
--
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)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
Re: parsing radius voip 