tol_iwan Опубликовано 19 сентября, 2012 · Жалоба Есть АТС - TDA. Для связи с SIP-провайдером стоит YATE. Соединены по h.323 - в TDA IPGW4 и 16. Звонки от провайдера на внутренние номера TDA и YATE приходят нормально. Звонки от абонента YATE к абоненту TDA проходят нормально. Проблема со звонками от абонента TDA к абоненту YATE - сам звонок идет, но как только на YATE снимают трубку - идет отбой. Где-то вычитывал, что версии h.323 в TDA и YATE разные (2 и 4), но думаю тогда не проходили бы звонки вообще, если бы проблема в этом была. Пробовал менять кодеки - ничего. Мож кто сталкивался с проблемой? Маршрутизацию через YATE на SIP-провайдера для звонка в город не делал, т.к. не актуально, но думаю проблема будет и там. Далее вырезка из логов, где происходит обрыв(полностью лог звонка громоздко думаю). Инфа: 2136 - абонент TDA 102 - абонент YATE(выход с TDA по коду 27, в YATE 27XXX заворачиваются на внутренний XXX) 172.16.0.10 - стоит YATE 172.16.2.11 - стоит YATE-клиент, подключен к YATE по SIP 172.16.0.107 - TDA В клиенте YATE: BYE sip:102@172.16.2.11:2634 SIP/2.0 Call-ID: 1718712306@172.16.0.10 From: <sip:2136@172.16.0.10>;tag=1274164220 To: <sip:102@172.16.2.11:2634>;tag=631052321 Reason: SIP;text="EndedByQ931Cause" P-RTP-Stat: PS=0,OS=0,PR=2,OR=320,PL=0 Via: SIP/2.0/UDP 172.16.0.10:5060;rport;branch=z9hG4bK200302549 CSeq: 14 BYE User-Agent: YATE/4.2.0 Max-Forwards: 70 Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, INFO Content-Length: 0 В TDA: PBX->QSIG line No.502 Port:2 (elapsed time from LPR reset) 01/01/03 10:07:44 L2: I SAPI:0 TEI:0 L3: CONNECT ACK crn:0048 (O) 02 01 00 FA 08 01 48 0F QSIG line->PBX No.503 Port:2 (elapsed time from LPR reset) 01/01/03 10:07:44 L2: I SAPI:0 TEI:0 L3: DISCONNECT crn:0048 (D) Cause: 80 EF Cause Value= "#111 Protocol error, unspecified" Location= "user" 00 01 FA 00 08 01 C8 45 08 02 80 EF В логе YATE: <h323/2:ALL> YateH323Connection::rtpForward(013705D0,0) [0137A840] <h323/2:NOTE> Formats changed to 'alaw' <h323/2:ALL> Removing capability 'G.729A/B' (g729) not in remote 'alaw' <h323/2:ALL> Removing capability 'G.729A' (g729) not in remote 'alaw' <h323/2:ALL> Removing capability 'G.729B' (g729b) not in remote 'alaw' <h323/2:ALL> Removing capability 'G.729' (g729) not in remote 'alaw' <h323/2:ALL> YateH323Connection::CleanUpOnCallEnd() [0137A840] <h323/2:INFO> YateH323Connection::OnCleared() error: '(null)' reason: EndedByQ931Cause (23) [0137A840] <sip/2:ALL> YateSIPConnection::disconnected() 'EndedByQ931Cause' [013A1968] <h323/2:ALL> YateH323Chan::~YateH323Chan() ringing h323/2 [01371278] <h323/2:ALL> YateH323Connection::~YateH323Connection() [0137A840] <sip/2:ALL> YateSIPConnection::hangup() state=3 trans=00000000 error='noanswer' code=487 reason='EndedByQ931Cause' [013A1968] <yrtp:ALL> RTP/AVP message received <yrtp:ALL> Wrapper 01365A00 found by ID 'yrtp/592608329' <yrtp:INFO> YRTPWrapper::terminate() [01365A00] <yrtp:ALL> YRTPSource::~YRTPSource() [013A48F0] wrapper=01365A00 ts=160 <yrtp:ALL> YRTPConsumer::~YRTPConsumer() [0137F068] wrapper=01365A00 ts=0 <yrtp:ALL> YRTPWrapper::~YRTPWrapper() bidir 'audio' [01365A00] <ALL> Cleaning up RTP 0137F2D8 [01365A00] <sip/2:ALL> YateSIPConnection::~YateSIPConnection() [013A1968] <sip:INFO> 'udp:0.0.0.0:5060' sending 'BYE sip:102@172.16.2.11:2634' 0139B4A0 to 172.16.2.11:2634 [013568B8] Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tol_iwan Опубликовано 20 сентября, 2012 · Жалоба Мда, что совсем ни у кого нет мыслей? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tol_iwan Опубликовано 20 сентября, 2012 · Жалоба Я что единственный, кто пытается TDA с YATE подружить? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
facility Опубликовано 21 сентября, 2012 · Жалоба Я что единственный, кто пытается TDA с YATE подружить? Такую связку не настраивал, но могу помочь разобраться с протоколами. Запишите трафик и H.323 и SIP с помощью wireshark или tcpdump, и покажите общественности. Думаю, что это внесет ясность. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
All is not what it seems Опубликовано 21 сентября, 2012 · Жалоба Давайте сниф, как сказал предыдущий оратор. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tol_iwan Опубликовано 21 сентября, 2012 · Жалоба Wireshark не пользовался, посему саму выгрузку не совсем представляю как сделать - сделал как получилось в txt, если что еще нужно скажите. В файлах выборка по протоколам и по IP на один проблемный звонок с 2136(TDA) на 102(YATE). Подскажите, если как-то по-другому выгрузить нужно. P.S. Спасибо за ответы :-) отбой - sip.txt отбой - h245.txt отбой - h225_q931.txt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
All is not what it seems Опубликовано 21 сентября, 2012 · Жалоба нужно на выходе получить файлик с расширением .pcap Хелпа и интернета достаточно для понимания как это сделать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tol_iwan Опубликовано 21 сентября, 2012 · Жалоба Вот собранный файл. Архив т.к. *.pcap не дает здесь загружать. звонки.zip Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
All is not what it seems Опубликовано 21 сентября, 2012 · Жалоба Для начала оставте один кодек на всех плечах звонка, тоесть чтоб в TDA был только один, на H323 в яте, смотрящем в TDA, на SIP в яте в сторону YATE-клиента и на YATE-клиенте. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tol_iwan Опубликовано 24 сентября, 2012 · Жалоба Поставил только g711. Результат тот же. Интересно, что обратный звонок нормально проходит. В wireshark-е заметил одну разницу между двумя направлениями - в случае когда звонок YATE-TDA постоянно идут RTP-пакеты до снятия трубки 61172 22.422444000 172.16.2.11 172.16.0.10 RTP 214 PT=ITU-T G.711 PCMA, SSRC=0x7A2DB232, Seq=5666, Time=60615950 В случае с обратным звонком TDA-YATE эти пакеты появляются только после снятия трубки. Конечно может TDA и не должна их слать... Для сравнения привожу 2 файла со звонками в обоих направлениях: проблемный YATE-TDA и обратный нормальный TDA-YATE. Кодек везде стоит g711 на момент совершения вызовов. Длительное время(несколько секунд) не снимал специально трубку, чтобы по времени легче было видно момент снятия. Была мысли в "непропуске" файрволом, но сейчас жестко прописал весь трафик между адресами пропускать. звонки в обоих направлениях.zip Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
All is not what it seems Опубликовано 24 сентября, 2012 · Жалоба Сейчас не имею возможности детально изучить последний сниф, пока предлагаю поигратся параметрами FastStart, H.245 Tunneling, Early H.245(может у вас называтся немного не так), и на Яте и на паносонике. Снифы собирайте и выложите. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tol_iwan Опубликовано 24 сентября, 2012 · Жалоба Думаю ранее выложенный сниф не совсем верен, т.к. снимался на 172.16.2.11, т.е. на клиенте YATE. Во вложенном такие же звонки, но на сервере YATE(172.16.0.10). По поводу замеченных мной RTP-пакетов до снятия трубки разобрался - это FastStart. При изменениях на TDA и YATE ничего со звонками не меняется. Сейчас убрал , т.к. без этого снифы более читабельны. H.245 Tunneling вроде игрался, но попробую еще, а вот Early H.245 - не встречал такого параметра. звонки в обоих направлениях.zip Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tol_iwan Опубликовано 24 сентября, 2012 · Жалоба Обратил внимание, что при отбойном звонке в снифе вообще отсутствует адрес TDA - 172.16.0.107. С чем связано не могу понять. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nonoma72 Опубликовано 24 сентября, 2012 (изменено) · Жалоба у меня tda-200 c помощью ip-gwa4 подключена к asterisk. была проблема в односторонней слышимости, вопрос решился Call Signaling Model переведя в Routed (via Gatekeeper) могу настройками поделитсья Изменено 24 сентября, 2012 пользователем nonoma72 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
facility Опубликовано 24 сентября, 2012 (изменено) · Жалоба Вот собранный файл. Архив т.к. *.pcap не дает здесь загружать. Единственная правильная запись. Во всех остальных только SIP. Предполагаю, что проблема у Вас из-за того, что YATE в сообщении CONNECT передает параметр h245Address в то время, как канал H.245 уже установлен и по нему идет обмен сообщениями. Это либо проблема библиотеки H.323, которую использует YATE, либо проблема самого YATE. Для начала попробуйте использовать H323Plus (http://www.h323plus.org) вместо используемой Вами OpenH323 1.19. Изменено 24 сентября, 2012 пользователем facility Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tol_iwan Опубликовано 25 сентября, 2012 · Жалоба у меня tda-200 c помощью ip-gwa4 подключена к asterisk. у меня у самого TDA200 подключена к AVAYA CM по h323 и нормально работает. А вот к YATE никак не хочет. Предполагаю, что проблема у Вас из-за того, что YATE в сообщении CONNECT передает параметр h245Address в то время, как канал H.245 уже установлен и по нему идет обмен сообщениями Может быть конечно - при успешном обратном звонке этого параметра нет. Уже не знаю с какими параметрами экспериментировать... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
facility Опубликовано 25 сентября, 2012 · Жалоба у меня tda-200 c помощью ip-gwa4 подключена к asterisk. у меня у самого TDA200 подключена к AVAYA CM по h323 и нормально работает. А вот к YATE никак не хочет. Тут нет ошибок со стороны TDA. Это ошибка со стороны YATE. Предполагаю, что проблема у Вас из-за того, что YATE в сообщении CONNECT передает параметр h245Address в то время, как канал H.245 уже установлен и по нему идет обмен сообщениями Может быть конечно - при успешном обратном звонке этого параметра нет. Уже не знаю с какими параметрами экспериментировать... А ни с какими. Это ошибка в программном коде. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tol_iwan Опубликовано 25 сентября, 2012 · Жалоба Не сказал кстати - использую YATE под Windows. Хотя тут думаю не должно быть проблем. Может я в яте где-то совсем плохо настроил - во вложении все мои настройки. Может подсоветуете, вдруг какой косяк сильный. conf.d.zip Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
All is not what it seems Опубликовано 25 сентября, 2012 · Жалоба Нужно искать как на яте выключить передачу h245Address до коннекта или как на панасонике сделать чтобы этот параметр до коннекта игнорировался. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tol_iwan Опубликовано 25 сентября, 2012 · Жалоба А ни с какими. Это ошибка в программном коде Хотите сказать - бесполезно скрещивать YATE с TDA? Может быть конечно, но ошибка идет как несоответствие протокола - я бы понял, если бы звонок тогда в обе стороны не проходил, т.к. ведь нет, только в одну, в обратную нормально звонит. Я конечно не специалист в VoIP и в h323 в частности, но мысли такие вот. И получается действительно никто не скрещивал эти две АТС... У меня сейчас стоит двойная схема : город-YATE-AVAYA-оператор и оператор-AVAYA-TDA-телефонная сеть организации. Имея в центре перехода оператор-остальная телефония AVAYA имею ограничения по лицензиям и прочие неудобства. А тут еще и хочется часть офиса перевести на SIP. Я даже думаю, что связка TDA-AVAYA-YATE сработает для обхода существующей проблемы, но это слишком хитрая схема и слишком сложная маршрутизация. Это кроме необходимости докупа недостающих лицензий. Вообще кажется глупым использовать AVAYA для связи TDA и YATE. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tol_iwan Опубликовано 25 сентября, 2012 (изменено) · Жалоба Нужно искать как на яте выключить передачу h245Address до коннекта или как на панасонике сделать чтобы этот параметр до коннекта игнорировался На панасонике нет таких настроек. Все, что есть: Port No. Settings H.225 Port No. 1720 H.245 Port No. 1721 RAS Port No. 1719 RTP/RTCP Port No. 5004 Voice CODEC Settings Voice CODEC Priority 1st G711 2nd none 3rd none 4th none Gatekeeper Settings Gatekeeper - Use / Don't use Primary Gatekeeper IP Address Primary Gatekeeper Port No. Secondary Gatekeeper IP Address Secondary Gatekeeper Port No. Gatekeeper Connection Checking Interval (min) 0-1440min Call Signaling Model Direct / Routed (via Gatekeeper) Others Fast Connect Use / Don't use Это все - больше ничего нет... Так что вариант с YATE как-то больше подходит. Конечно заменить на H323Plus тоже можно попробовать, но тут я даже не знаю с какой стороны подходить. А почему YATE вставляет h245Address только в одном направлении? Мне это покоя не дает... Изменено 25 сентября, 2012 пользователем tol_iwan Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
facility Опубликовано 26 сентября, 2012 · Жалоба Тут сначала надо представить что происходит, и тогда, возможно, найдейтся какое-нибудь обходное решение. Такая ситуация возникает из-за того, что канал H.245 организуется через отдельное TCP-соединение. В режиме "быстрого соединения" (Fast Connect) или "туннелирования H.245" (H.245 Tunelling) ее быть не может. Инициатором такого способа организации канала H.245 является TDA, и, насколько я вижу, можно ПОПРОБОВАТЬ вместо него использовать Быстрое соединение. Включите опцию Fast Connect (значение "Use") на TDA и запишите трафик H.323 с помощью WireShark. P.S. Avaya Communication Manager всегда начинает установку вызова с предложением ипользовать Быстрое соединение. Возможно поэтому эта связка и работает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tol_iwan Опубликовано 26 сентября, 2012 · Жалоба Включите опцию Fast Connect (значение "Use") на TDA Пробовал, видимый результат тот же, WireShark не смотрел. Сейчас повторю - выложу файл. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tol_iwan Опубликовано 26 сентября, 2012 · Жалоба Вот файл. Выборка на YATE по фильтру (rtp or h245 or h225 or sip) and (ip.addr == 172.16.0.107 or ip.addr == 172.16.2.11 ) h323 в принципе там нет. Интересно, что faststart включен на обоих концах, а в меню WireShark telephony-VoIP Calls в обмене между TDA(IP 0.107) и YATE-сервером(IP 0.10) в комментарии написано, что faststart: off. И там же видно что в "setup OLC(g711A g711A)"(время 3.987065) FS:on, а назад идет "callProcaessing"(время 4.307985) и в нем уже FS:off. и при "connect"(время 16.06196), после которого TDA отвечает завершением, тоже самое: FS:off. YATE - h323chan.conf - [ep] faststart=true h323 tda-yate faststart-on.zip Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
facility Опубликовано 26 сентября, 2012 · Жалоба Интересно, что faststart включен на обоих концах ... YATE - h323chan.conf - [ep] faststart=true TDA предлагает использовать Быстрое соединение, YATE отказывается. Вообще, тут можно придираться к содержанию сообщений H.225.0. Например, начиная с H.323 версии 4, при использовании Быстрого соединения необходимо устанавливать значение h245Tunelling=True. Тем не менее, TDA этого не делает. Не факт, что это играет ключевую роль, но все же... В общем, вывод очевиден: YATE, несмотря на предложение от TDA, отказывается использовать Быстрое соединение. Как я уже писал, проблема может быть как в самом YATE (конфигурация, программный код), так и в OpenH323 1.19. Убедитесь, что правильно составили конфигурацию YATE. Попробуйте использовать H323Plus вместо OpenH323 (тут все достаточно просто). Если ничего не помогает, обратитесь к разработчикам YATE. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...