Проблема с сообщением SIP BYE - PullRequest
Новая
       44

Проблема с сообщением SIP BYE

3 голосов
/ 27 октября 2009

Я пишу SIP-сервер, и у меня он принимает звонки, а затем подключает их к VoIP-телефону, проблема в том, что когда вы вешаете VoIP-телефон, что-то не так с пересылкой сообщения BYE, где мой сотовый телефон не завершает звонок

Вот журнал сообщений SIP (я заменил номер телефона моего сервера на 1234, а номер телефона моего мобильного телефона на 5678, IP-адрес моего сервера был заменен на x, а IP-адрес моего VoIP-телефона был заменен на y) - 

Incoming from 174.37.45.134:5060 - 
INVITE sip:1234@174.37.45.134:5060;rinstance=f10c56ae7fb62958 SIP/2.0
Record-Route: <sip:174.37.45.134;lr=on;ftag=VPSF506071629460>
Record-Route: <sip:67.228.177.9;lr=on;ftag=VPSF506071629460>
Record-Route: <sip:216.82.224.202;lr;ftag=VPSF506071629460>
Record-Route: <sip:4.79.212.229;lr;ftag=VPSF506071629460>
Via: SIP/2.0/UDP 174.37.45.134;branch=z9hG4bK9767.ad406992.0
Via: SIP/2.0/UDP 67.228.177.9;rport=5060;branch=z9hG4bK9767.760c9624.0
Via: SIP/2.0/UDP 216.82.224.202;rport=5060;received=216.82.224.202;branch=z9hG4bK9767.823f8e12.0
Via: SIP/2.0/UDP 216.82.224.202;branch=z9hG4bK9767.723f8e12.0
Via: SIP/2.0/UDP 4.79.212.229;branch=z9hG4bK9767.e30c5303.0
Via: SIP/2.0/UDP 4.68.250.148:5060;branch=z9hG4bK506071629460-1256581032616
f: "Carro Ramon"  <sip:5678@4.68.250.148>;tag=VPSF506071629460
t: <sip:+11234@4.79.212.229:5060>
i: MIAMGC0120091027172219041244@209.244.63.32
CSeq: 1 INVITE
m: <sip:+15678@4.68.250.148:5060;transport=udp;nat=yes>
Max-Forwards: 64
c: application/sdp
Content-Length: 192

v=0
o=- 1256664139 1256664140 IN IP4 209.247.22.135
s=-
c=IN IP4 174.37.45.134
t=0 0
m=audio 55540 RTP/AVP 0 18 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=nortpproxy:yes

Outgoing to 174.37.45.134:5060 - 
SIP/2.0 180 Ringing
CSeq: 1 INVITE
Call-ID: MIAMGC0120091027172219041244@209.244.63.32
Contact: <sip:+15678@4.68.250.148:5060;transport=udp;nat=yes>
From: "Carro Ramon"  <sip:5678@4.68.250.148>;tag=VPSF506071629460
Max-Forwards: 70
Record-Route: <sip:174.37.45.134;lr=on;ftag=VPSF506071629460>, <sip:67.228.177.9;lr=on;ftag=VPSF506071629460>, <sip:216.82.224.202;lr;ftag=VPSF506071629460>, <sip:4.79.212.229;lr;ftag=VPSF506071629460>
To: <sip:+11234@4.79.212.229:5060>;tag=dAmXcBGL
Via: SIP/2.0/UDP 174.37.45.134;branch=z9hG4bK9767.ad406992.0, SIP/2.0/UDP 67.228.177.9;rport=5060;branch=z9hG4bK9767.760c9624.0, SIP/2.0/UDP 216.82.224.202;rport=5060;received=216.82.224.202;branch=z9hG4bK9767.823f8e12.0, SIP/2.0/UDP 216.82.224.202;branch=z9hG4bK9767.723f8e12.0, SIP/2.0/UDP 4.79.212.229;branch=z9hG4bK9767.e30c5303.0, SIP/2.0/UDP 4.68.250.148:5060;branch=z9hG4bK506071629460-1256581032616
Content-Length: 0

Outgoing to 174.37.45.134:5060 - 
SIP/2.0 200 OK
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO
CSeq: 1 INVITE
Call-ID: MIAMGC0120091027172219041244@209.244.63.32
Contact: <sip:+15678@4.68.250.148:5060;transport=udp;nat=yes>
Content-Type: application/sdp
From: "Carro Ramon"  <sip:5678@4.68.250.148>;tag=VPSF506071629460
Max-Forwards: 70
Record-Route: <sip:174.37.45.134;lr=on;ftag=VPSF506071629460>, <sip:67.228.177.9;lr=on;ftag=VPSF506071629460>, <sip:216.82.224.202;lr;ftag=VPSF506071629460>, <sip:4.79.212.229;lr;ftag=VPSF506071629460>
To: <sip:+11234@4.79.212.229:5060>;tag=BYFeP7T1
Via: SIP/2.0/UDP 174.37.45.134;branch=z9hG4bK9767.ad406992.0, SIP/2.0/UDP 67.228.177.9;rport=5060;branch=z9hG4bK9767.760c9624.0, SIP/2.0/UDP 216.82.224.202;rport=5060;received=216.82.224.202;branch=z9hG4bK9767.823f8e12.0, SIP/2.0/UDP 216.82.224.202;branch=z9hG4bK9767.723f8e12.0, SIP/2.0/UDP 4.79.212.229;branch=z9hG4bK9767.e30c5303.0, SIP/2.0/UDP 4.68.250.148:5060;branch=z9hG4bK506071629460-1256581032616
Content-Length: 206

v=0
o=Zoiper_user 0 0 IN IP4 xx.xx.xxx.xx
s=Zoiper_session
c=IN IP4 xx.xx.xxx.xx
t=0 0
m=audio 8000 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv

Incoming from 174.37.45.134:5060 - 
ACK sip:+15678@xx.xx.xxx.xx:5060;transport=udp SIP/2.0
Record-Route: <sip:174.37.45.134;lr=on;ftag=VPSF506071629460>
Record-Route: <sip:67.228.177.9;lr=on;ftag=VPSF506071629460>
Record-Route: <sip:216.82.224.202;lr;ftag=VPSF506071629460>
Via: SIP/2.0/UDP 174.37.45.134;branch=z9hG4bK9767.ad406992.2
Via: SIP/2.0/UDP 67.228.177.9;rport=5060;branch=z9hG4bK9767.760c9624.2
Via: SIP/2.0/UDP 216.82.224.202;rport=5060;received=216.82.224.202;branch=z9hG4bK9767.723f8e12.2
Via: SIP/2.0/UDP 4.79.212.229;branch=z9hG4bK9767.e30c5303.2
Via: SIP/2.0/UDP 4.68.250.148:5060;branch=z9hG4bK506071629460-1256581032653
From: "CARRO RAMON    "  <sip:+15678@4.68.250.148;isup-oli=0>;tag=VPSF506071629460
To: <sip:+11234@4.79.212.229:5060>;tag=BYFeP7T1
Call-ID: MIAMGC0120091027172219041244@209.244.63.32
CSeq: 1 ACK
Contact: <sip:4.68.250.148:5060;transport=udp>
Max-Forwards: 66
Content-Length: 0

Outgoing to yyy.yyy.yy.yyy:1024 - 
INVITE sip:3998@192.168.1.121 SIP/2.0
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO
CSeq: 1 INVITE
Call-ID: AW6zfKQ8RWl71MipIe4X1WWKfw7xGGR9@chat.seohosting.com
Contact: <sip:5678@xx.xx.xxx.xx>;transport=UDP
Content-Type: application/sdp
From: "(null)" <sip:5678@xx.xx.xxx.xx>;transport=UDP;tag=7b2add35
Max-Forwards: 70
To: <sip:3998@xx.xx.xxx.xx>
User-Agent: Zoiper rev.4186
Via: SIP/2.0/UDP xx.xx.xxx.xx:5060
Content-Length: 206

v=0
o=Zoiper_user 0 0 IN IP4 xx.xx.xxx.xx
s=Zoiper_session
c=IN IP4 xx.xx.xxx.xx
t=0 0
m=audio 8000 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv

Incoming from yyy.yyy.yy.yyy:1024 - 
SIP/2.0 100 Trying
To: <sip:3998@xx.xx.xxx.xx>
From: "(null)" <sip:5678@xx.xx.xxx.xx>;transport=UDP;tag=7b2add35
Call-ID: AW6zfKQ8RWl71MipIe4X1WWKfw7xGGR9@chat.seohosting.com
CSeq: 1 INVITE
Via: SIP/2.0/UDP xx.xx.xxx.xx:5060
Server: Linksys/SPA941-5.1.8
Content-Length: 0


Incoming from yyy.yyy.yy.yyy:1024 - 
SIP/2.0 180 Ringing
To: <sip:3998@xx.xx.xxx.xx>;tag=53cca4372c533924i0
From: "(null)" <sip:5678@xx.xx.xxx.xx>;transport=UDP;tag=7b2add35
Call-ID: AW6zfKQ8RWl71MipIe4X1WWKfw7xGGR9@chat.seohosting.com
CSeq: 1 INVITE
Via: SIP/2.0/UDP xx.xx.xxx.xx:5060
Server: Linksys/SPA941-5.1.8
Content-Length: 0

Incoming from yyy.yyy.yy.yyy:1024 - 
SIP/2.0 200 OK
To: <sip:3998@xx.xx.xxx.xx>;tag=53cca4372c533924i0
From: "(null)" <sip:5678@xx.xx.xxx.xx>;transport=UDP;tag=7b2add35
Call-ID: AW6zfKQ8RWl71MipIe4X1WWKfw7xGGR9@chat.seohosting.com
CSeq: 1 INVITE
Via: SIP/2.0/UDP xx.xx.xxx.xx:5060
Contact: "3998" <sip:3998@192.168.1.121:5060>
Server: Linksys/SPA941-5.1.8
Content-Length: 212
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: replaces
Content-Type: application/sdp

v=0
o=- 49591664 49591664 IN IP4 192.168.1.121
s=-
c=IN IP4 192.168.1.121
t=0 0
m=audio 16432 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:30
a=sendrecv

Outgoing to yyy.yyy.yy.yyy:1024 - 
ACK sip:3998@192.168.1.121 SIP/2.0
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO
CSeq: 1 ACK
Call-ID: AW6zfKQ8RWl71MipIe4X1WWKfw7xGGR9@chat.seohosting.com
Contact: <sip:5678@xx.xx.xxx.xx>;transport=UDP
From: "(null)" <sip:5678@xx.xx.xxx.xx>;transport=UDP;tag=7b2add35
Max-Forwards: 70
To: <sip:3998@xx.xx.xxx.xx>;tag=53cca4372c533924i0
User-Agent: Zoiper rev.4186
Via: SIP/2.0/UDP xx.xx.xxx.xx:5060
Content-Length: 0

Incoming from yyy.yyy.yy.yyy:1024 - 
BYE sip:5678@xx.xx.xxx.xx SIP/2.0
Via: SIP/2.0/UDP 192.168.1.121:5060;branch=z9hG4bK-598f1319
From: <sip:3998@xx.xx.xxx.xx>;tag=53cca4372c533924i0
To: "(null)" <sip:5678@xx.xx.xxx.xx>;tag=7b2add35
Call-ID: AW6zfKQ8RWl71MipIe4X1WWKfw7xGGR9@chat.seohosting.com
CSeq: 101 BYE
Max-Forwards: 70
User-Agent: Linksys/SPA941-5.1.8
Content-Length: 0

Outgoing to 174.37.45.134:5060 - 
BYE sip:5678@4.68.250.148 SIP/2.0
CSeq: 2 BYE
Call-ID: MIAMGC0120091027172219041244@209.244.63.32
Contact: <sip:1234@xx.xx.xxx.xx>
From: <sip:+11234@4.79.212.229:5060>;tag=BYFeP7T1
Max-Forwards: 70
Route: <sip:174.37.45.134;lr=on;ftag=VPSF506071629460>, <sip:67.228.177.9;lr=on;ftag=VPSF506071629460>, <sip:216.82.224.202;lr;ftag=VPSF506071629460>
To: "CARRO RAMON    "  <sip:+15678@4.68.250.148;isup-oli=0>;tag=VPSF506071629460
Via: SIP/2.0/UDP 174.37.45.134:5060
Content-Length: 0

Outgoing to yyy.yyy.yy.yyy:1024 - 
SIP/2.0 200 OK
CSeq: 101 BYE
Call-ID: AW6zfKQ8RWl71MipIe4X1WWKfw7xGGR9@chat.seohosting.com
From: <sip:3998@xx.xx.xxx.xx>;tag=53cca4372c533924i0;tag=D1EASwOG
Max-Forwards: 70
To: "(null)" <sip:5678@xx.xx.xxx.xx>;tag=7b2add35
Via: SIP/2.0/UDP 192.168.1.121:5060;branch=z9hG4bK-598f1319

Incoming from 174.37.45.134:5060 - 
SIP/2.0 408 Request Timeout
CSeq: 2 BYE
Call-ID: MIAMGC0120091027172219041244@209.244.63.32
From: <sip:+11234@4.79.212.229:5060>;tag=BYFeP7T1
To: "CARRO RAMON    "  <sip:+15678@4.68.250.148;isup-oli=0>;tag=VPSF506071629460
Via: SIP/2.0/UDP 174.37.45.134:5060;rport=5060;received=xx.xx.xxx.xx
Server: Kamailio (1.5.2-notls (x86_64/linux))
Content-Length: 0
Warning: 392 67.228.177.9:5060 "Noisy feedback tells:  pid=15004 req_src_ip=174.37.45.134 req_src_port=5060 in_uri=sip:5678@4.68.250.148 out_uri=sip:5678@4.68.250.148 via_cnt==1092"

Ответы [ 5 ]

3 голосов
/ 27 октября 2009

Возможно, вы захотите проверить, что говорит значение заголовка предупреждения. Есть специальное сообщение «Шумная обратная связь говорит» ... это очень специфично для приложения. Сообщения Тайм-аут запроса обычно эмулируются стеком по истечении времени ожидания транзакции. Это может означать, что ваш запрос BYE к 174.37.45.134:5060 не может достичь пункта назначения. Это также может быть в том случае, если исходный запрос BYE искажен, а другая сторона его игнорирует.

Вы пытались отладить свой сервер локально с помощью SIPp ?
Вы также можете запустить Ethereal ( Wireshark ), чтобы проверить ваш трафик.

0 голосов
/ 14 октября 2013

RFC 3261 требует, чтобы числа (URI), связанные в полях «Кому» и «От», оставались одинаковыми. Если задействован NAT, IP-адреса могут измениться, однако цифры должны оставаться постоянными. Если вы заметили, поля «Кому» и «От» в заголовке BYE поменялись местами, что сделало пакет некорректным.

0 голосов
/ 05 декабря 2012

Если вы хотите соответствовать RFC 3261, обязательно, чтобы отправляемые вами заголовки "Via" включали необязательный (!) Параметр "branch".

См. RFC3261 сс 20.42:

Даже если эта спецификация требует, чтобы параметр ветви был присутствующий во всех запросах, BNF для поля заголовка указывает, что это необязательно. Это позволяет взаимодействовать с элементами RFC 2543, который не должен был вставлять параметр ветви.

0 голосов
/ 06 ноября 2009

Я бы порекомендовал проверить, принимает ли вызывающая сторона запрос BYE (похоже, он принимает, но ...) и как он обрабатывает этот запрос. Что вам действительно нужно, это аналог журнала из 174.37.45.134. Кажется, проблема позади .134 (время ожидания было сгенерировано .134).

Кстати, на первый взгляд, я вижу, что вы нарушаете несколько основных правил обработки вызовов, которые могут привести к таким проблемам: - Вы пропускаете попытку ответа на исходящий вызов. Если стек SIP отправителя действительно ожидает этого, это может привести к тому, что идентификатор вызова не будет действительно записан. Да, это плохое поведение, но мы живем в реальном мире. Стандарты говорят, что нужно ответить как можно быстрее (даже до того, как вы выполните маршрутизацию, сразу после аутентификации вызова) - Вы полностью устанавливаете сеанс вызова с вызывающей стороной еще до того, как инициируете исходящее сообщение INVITE для вызываемой стороны. Это неправильная логика. Хотя бы потому, что в случае сбоя исходящего звонка отправителю будет выставлен счет.

Если вы можете сделать это быстро, я бы рекомендовал сначала исправить последовательность настройки вызова. В любом случае вам это понадобится, и есть вероятность, что это исправит завершение вызова: 

INVITE  ->
TRYING  <-
        -> INVITE
        <- TRYING
        <- RINGING
RINGING <-
        <- OK
OK      <-
ACK     ->
        -> ACK
0 голосов
/ 29 октября 2009

"via_cnt == 1092" также очень подозрительно.

Кстати, вы, похоже, строите B2BUA, в котором вы принимаете вызов извне, даже не отправив приглашение на местный телефон (1234). Если локальный телефон должен был принимать другие параметры, принять другой кодек и т. Д., Вы были бы облажаны, так как вы сказали локальному телефону отправлять мультимедиа непосредственно исходному абоненту. Они действительно должны отправлять свои медиа на ваш сервер, который будет ретранслировать (или при необходимости транскодировать).

Если вы не хотите этого делать (т.е. вы не хотите выступать в роли медиа-реле и возможного транскодера), вам нужно переслать сообщение INVITE на локальный телефон, затем переслать любой ответ и т. Д. в качестве прокси-сервера SIP, а не SIP B2BUA.

...