SIP сигнализация. Поле branch

busc · Сообщение **busc** » 21 июл 2011, 15:11

Вопрос в следующем.
Заметил что в одном направлении у меня по таймауту отваливаются звонки на транзите.
Схема такая:

Пров - Основной SIPProxy - Asterisk - Абонент

Звонок идет от абонента * в направлении прова.
После изучения sip трейса нашел следующее:
Когда на стороне прова снимают трубку то идет сообщение 200 ОК на Основной SIPProxy, от него на * ...
В ответ каждый из узлов в свою очередь отдает ACK.
Так вот на стыке SIPProxy - Asterisk, АСК приходит * -> SIPProxy а дальше сообщение не передается.
Пров не дожидается АСК и после нескольких Retry отрывает связь.
Изучал сигнализацию и вот что показалось подозрительным

U 2011/07/21 16:25:45.327063 SIPProxy:5060 -> Asterisk:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP Asterisk_addr2:5060;branch=z9hG4bK20d70468;rport.
...

U 2011/07/21 16:25:45.328693 Asterisk:5060 -> SIPProxy:5060
ACK sip:[email protected]:5060;user=phone SIP/2.0.
Via: SIP/2.0/UDP Asterisk_addr2:5060;branch=z9hG4bK5e3eef8f;rport.
Max-Forwards: 70.
...

Собственно смутил разный номер branch в ответе и подтверждении получения ответа.
Это нормально или нет? Я думаю что из-за этого SIPProxy игнорировал АСК, поскольку небыло разговора с таким бранчем.

Собственно вопрос - я заблуждаюсь или это баг Asterisk?

just_user · Сообщение **just_user** » 21 июл 2011, 19:16

Поправьте меня, если я не прав, но судя по RFC 3261:

an ACK for a non-2xx response will also have the same branch ID as the INVITE whose response it acknowledges.

Другими словами, branch в ACK на ответ 200 ОК не должен совпадать с branch в самом 200 ОК (который изначально содержит branch INVITE'a)

busc · Сообщение **busc** » 21 июл 2011, 22:43

Похоже да, но где искать собаку?
С аналогичными настройками (1 к 1 вся цепь, кроме прова) сигнализация нормально ретранслируется нигде не застряет.
Во что смотреть? какие поля проверять. Рылся в базе багов, там есть похожие но для старых версий 1.2, 1.4, и давно все пофикшено.

just_user · Сообщение **just_user** » 22 июл 2011, 04:06

Есть возможность снять дамп между Провайдером и SIPProxy ?

busc · Сообщение **busc** » 22 июл 2011, 09:54

Конечно есть, что искать? от прова приходит на SIPProxy 200 ОК,
потом 200 ОК идет на *
* отвечает ACK на SIPProxy
и дальше это никуда не идет.
SIPProxy повторяет 1 раз 200 ОК, притом сразу (моментально)!
Провайдер повторяет несколько раз 200 ОК, но больше ничего не происходит.
Вот полный текст сообщений
[spoiler]

U 2011/07/21 16:25:45.289733 Provider:5060 -> SIPProxy:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP SIPProxy:5060;branch=z9hG4bK-2c131100ff282810ff00001517ffff07;rport=5060.
Call-ID: [email protected]
From: <sip:[email protected];user=phone>;tag=6a111100ff282810ff00001517ffff07.
To: <sip:[email protected]:5060;user=phone>;tag=f2f63927-CC-22.
CSeq: 1 INVITE.
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER.
Contact: <sip:Provider:5060;user=phone>.
Content-Length: 163.
Content-Type: application/sdp.
.
v=0.
o=HuaweiSoftX3000 6467867 6467868 IN IP4 Provider.
s=Sip Call.
c=IN IP4 Provider.
t=0 0.
m=audio 14972 RTP/AVP 8.
a=rtpmap:8 PCMA/8000.
a=ptime:20.

U 2011/07/21 16:25:45.327063 SIPProxy:5060 -> Asterisk:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP Asterisk_addr2:5060;branch=z9hG4bK20d70468;rport.
From: "AbnName" <sip:[email protected]_addr2>;tag=as32b78017.
To: <sip:[email protected]>;tag=00ff0600ff282810ff00001517ffff07.
Call-ID: [email protected]_addr2.
CSeq: 102 INVITE.
Contact: <sip:[email protected]:5060;user=phone>.
Server: SIPProxy
Content-Type: application/sdp.
Content-Length: 264.
.
v=0.
o=- 1311254745 1311254745 IN IP4 SIPProxy.
s=-.
c=IN IP4 SIPProxy.
t=0 0.
m=audio 24980 RTP/AVP 0 8 18 4 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:18 G729/8000.
a=rtpmap:4 G723/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.

U 2011/07/21 16:25:45.328693 Asterisk:5060 -> SIPPRoxy:5060
ACK sip:[email protected]:5060;user=phone SIP/2.0.
Via: SIP/2.0/UDP Asterisk_addr2:5060;branch=z9hG4bK5e3eef8f;rport.
Max-Forwards: 70.
From: "AbnName" <sip:[email protected]_addr2>;tag=as32b78017.
To: <sip:[email protected]>;tag=00ff0600ff282810ff00001517ffff07.
Contact: <sip:[email protected]_addr2>.
Call-ID: [email protected]_addr2.
CSeq: 102 ACK.
User-Agent: Asterisk PBX 1.6.2.12.
Content-Length: 0.
.

U 2011/07/21 16:25:45.327063 SIPProxy:5060 -> Asterisk:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP Asterisk_addr2:5060;branch=z9hG4bK20d70468;rport.
From: "AbnName" <sip:[email protected]_addr2>;tag=as32b78017.
To: <sip:[email protected]>;tag=00ff0600ff282810ff00001517ffff07.
Call-ID: [email protected]_addr2.
CSeq: 102 INVITE.
Contact: <sip:[email protected]:5060;user=phone>.
Server: SIPProxy
Content-Type: application/sdp.
Content-Length: 264.
.
v=0.
o=- 1311254745 1311254745 IN IP4 SIPProxy.
s=-.
c=IN IP4 SIPProxy.
t=0 0.
m=audio 24980 RTP/AVP 0 8 18 4 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:18 G729/8000.
a=rtpmap:4 G723/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.

U 2011/07/21 16:25:45.289733 Provider:5060 -> SIPProxy:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP SIPProxy:5060;branch=z9hG4bK-2c131100ff282810ff00001517ffff07;rport=5060.
Call-ID: [email protected]
From: <sip:[email protected];user=phone>;tag=6a111100ff282810ff00001517ffff07.
To: <sip:[email protected]:5060;user=phone>;tag=f2f63927-CC-22.
CSeq: 1 INVITE.
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER.
Contact: <sip:Provider:5060;user=phone>.
Content-Length: 163.
Content-Type: application/sdp.
.
v=0.
o=HuaweiSoftX3000 6467867 6467868 IN IP4 Provider.
s=Sip Call.
c=IN IP4 Provider.
t=0 0.
m=audio 14972 RTP/AVP 8.
a=rtpmap:8 PCMA/8000.
a=ptime:20.

U 2011/07/21 16:25:45.289733 Provider:5060 -> SIPProxy:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP SIPProxy:5060;branch=z9hG4bK-2c131100ff282810ff00001517ffff07;rport=5060.
Call-ID: [email protected]
From: <sip:[email protected];user=phone>;tag=6a111100ff282810ff00001517ffff07.
To: <sip:[email protected]:5060;user=phone>;tag=f2f63927-CC-22.
CSeq: 1 INVITE.
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER.
Contact: <sip:Provider:5060;user=phone>.
Content-Length: 163.
Content-Type: application/sdp.
.
v=0.
o=HuaweiSoftX3000 6467867 6467868 IN IP4 Provider.
s=Sip Call.
c=IN IP4 Provider.
t=0 0.
m=audio 14972 RTP/AVP 8.
a=rtpmap:8 PCMA/8000.
a=ptime:20.

[/spoiler]
Если дело не в branch, то где?

Added after 1 hours 23 minutes:

Проблема обнаружена!
Это из-за ip_nat_sip модуля iptables на SIPProxy. Но если его отключить у меня не работает линк с другим провайдером.
Обсуждения этого зверя на форуме перечитал, что делать со всем этим - не понял

.

sipmarket · Сообщение **sipmarket** » 05 сен 2011, 13:48

Попробуйте поковырятся в настройках.
Может сделать проброс портов.
Вообще в этом случае помогает нестандартный порт на стороне провайдера.
Либо TCP/TLS.

Можем дать возможность проверить на нестандартном порту.
Посмотрите лог со стороны сервера.
Если нужно обращайтесь...

busc · Сообщение **busc** » 05 сен 2011, 14:46

Извиняюсь...
А причем тут нестандартный порт, причем тут проброс порта, TLS и остальное.
В каких настройках вы предлагаете поковыряться?

Если вы посмотрите в сигнализацию, то увидите, что * отдает нормальный пакет. Что ковырять?
На стороне SIPProxy включался модуль iptables для того чтобы использовать SIP nat. Когда он включен - SIPProxy ничего не делает с ответом от *.

Ваше сообщение выглядит как реклама. Или мой разум не восприимчив к советам и я прошу прощения.