[tol_iwan]

Есть АТС - 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]

[tol_iwan]

Мда, что совсем ни у кого нет мыслей?

[tol_iwan]

Я что единственный, кто пытается TDA с YATE подружить?

[facility]

Я что единственный, кто пытается TDA с YATE подружить?

Такую связку не настраивал, но могу помочь разобраться с протоколами. Запишите трафик и H.323 и SIP с помощью wireshark или tcpdump, и покажите общественности. Думаю, что это внесет ясность.

[All is not what it seems]

Давайте сниф, как сказал предыдущий оратор.

[tol_iwan]

Wireshark не пользовался, посему саму выгрузку не совсем представляю как сделать - сделал как получилось в txt, если что еще нужно скажите. В файлах выборка по протоколам и по IP на один проблемный звонок с 2136(TDA) на 102(YATE).

Подскажите, если как-то по-другому выгрузить нужно.

 

P.S. Спасибо за ответы :-)

отбой - sip.txt

отбой - h245.txt

отбой - h225_q931.txt

[All is not what it seems]

нужно на выходе получить файлик с расширением .pcap

Хелпа и интернета достаточно для понимания как это сделать.

[tol_iwan]

Вот собранный файл. Архив т.к. *.pcap не дает здесь загружать.

звонки.zip

[All is not what it seems]

Для начала оставте один кодек на всех плечах звонка, тоесть чтоб в TDA был только один, на H323 в яте, смотрящем в TDA, на SIP в яте в сторону YATE-клиента и на YATE-клиенте.

[tol_iwan]

Поставил только 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

[All is not what it seems]

Сейчас не имею возможности детально изучить последний сниф, пока предлагаю поигратся параметрами FastStart, H.245 Tunneling, Early H.245(может у вас называтся немного не так), и на Яте и на паносонике.

Снифы собирайте и выложите.

[tol_iwan]

Думаю ранее выложенный сниф не совсем верен, т.к. снимался на 172.16.2.11, т.е. на клиенте YATE.

Во вложенном такие же звонки, но на сервере YATE(172.16.0.10).

 

По поводу замеченных мной RTP-пакетов до снятия трубки разобрался - это FastStart. При изменениях на TDA и YATE ничего со звонками не меняется. Сейчас убрал , т.к. без этого снифы более читабельны.

H.245 Tunneling вроде игрался, но попробую еще, а вот Early H.245 - не встречал такого параметра.

звонки в обоих направлениях.zip

[tol_iwan]

Обратил внимание, что при отбойном звонке в снифе вообще отсутствует адрес TDA - 172.16.0.107. С чем связано не могу понять.

[nonoma72]

у меня tda-200 c помощью ip-gwa4 подключена к asterisk.

была проблема в односторонней слышимости, вопрос решился Call Signaling Model переведя в Routed (via Gatekeeper)

 

могу настройками поделитсья

Изменено 24 сентября, 2012 пользователем nonoma72

[facility]

Вот собранный файл. Архив т.к. *.pcap не дает здесь загружать.

Единственная правильная запись. Во всех остальных только SIP.

 

Предполагаю, что проблема у Вас из-за того, что YATE в сообщении CONNECT передает параметр h245Address в то время, как канал H.245 уже установлен и по нему идет обмен сообщениями. Это либо проблема библиотеки H.323, которую использует YATE, либо проблема самого YATE. Для начала попробуйте использовать H323Plus (http://www.h323plus.org) вместо используемой Вами OpenH323 1.19.

Изменено 24 сентября, 2012 пользователем facility

[tol_iwan]

у меня tda-200 c помощью ip-gwa4 подключена к asterisk.

у меня у самого TDA200 подключена к AVAYA CM по h323 и нормально работает. А вот к YATE никак не хочет.

Предполагаю, что проблема у Вас из-за того, что YATE в сообщении CONNECT передает параметр h245Address в то время, как канал H.245 уже установлен и по нему идет обмен сообщениями

Может быть конечно - при успешном обратном звонке этого параметра нет.

 

Уже не знаю с какими параметрами экспериментировать...

[facility]

у меня tda-200 c помощью ip-gwa4 подключена к asterisk.

у меня у самого TDA200 подключена к AVAYA CM по h323 и нормально работает. А вот к YATE никак не хочет.

Тут нет ошибок со стороны TDA. Это ошибка со стороны YATE.

Предполагаю, что проблема у Вас из-за того, что YATE в сообщении CONNECT передает параметр h245Address в то время, как канал H.245 уже установлен и по нему идет обмен сообщениями

Может быть конечно - при успешном обратном звонке этого параметра нет.

 

Уже не знаю с какими параметрами экспериментировать...

А ни с какими. Это ошибка в программном коде.

[tol_iwan]

Не сказал кстати - использую YATE под Windows. Хотя тут думаю не должно быть проблем.

Может я в яте где-то совсем плохо настроил - во вложении все мои настройки. Может подсоветуете, вдруг какой косяк сильный.

conf.d.zip

[All is not what it seems]

Нужно искать как на яте выключить передачу h245Address до коннекта или как на панасонике сделать чтобы этот параметр до коннекта игнорировался.

[tol_iwan]

А ни с какими. Это ошибка в программном коде

Хотите сказать - бесполезно скрещивать YATE с TDA? Может быть конечно, но ошибка идет как несоответствие протокола - я бы понял, если бы звонок тогда в обе стороны не проходил, т.к. ведь нет, только в одну, в обратную нормально звонит. Я конечно не специалист в VoIP и в h323 в частности, но мысли такие вот.

И получается действительно никто не скрещивал эти две АТС...

 

У меня сейчас стоит двойная схема : город-YATE-AVAYA-оператор и оператор-AVAYA-TDA-телефонная сеть организации. Имея в центре перехода оператор-остальная телефония AVAYA имею ограничения по лицензиям и прочие неудобства. А тут еще и хочется часть офиса перевести на SIP. Я даже думаю, что связка TDA-AVAYA-YATE сработает для обхода существующей проблемы, но это слишком хитрая схема и слишком сложная маршрутизация. Это кроме необходимости докупа недостающих лицензий. Вообще кажется глупым использовать AVAYA для связи TDA и YATE.

[tol_iwan]

Нужно искать как на яте выключить передачу 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

[facility]

Тут сначала надо представить что происходит, и тогда, возможно, найдейтся какое-нибудь обходное решение. Такая ситуация возникает из-за того, что канал 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 всегда начинает установку вызова с предложением ипользовать Быстрое соединение. Возможно поэтому эта связка и работает.

[tol_iwan]

Включите опцию Fast Connect (значение "Use") на TDA

Пробовал, видимый результат тот же, WireShark не смотрел. Сейчас повторю - выложу файл.

[tol_iwan]

Вот файл. Выборка на 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

[facility]

Интересно, что 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.