Problema con il messaggio SIP BYE
https://stackoverflow.com/questions/1632499
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
Sto scrivendo un server SIP, e faccio in modo che prenda le chiamate e poi le colleghi a un telefono VoIP, il problema è quando si riaggancia il telefono VoIP, c'è qualcosa di sbagliato nell'inoltro del messaggio BYE in cui il mio telefono cellulare non termina la chiamata.
Ecco il registro dei messaggi SIP (ho sostituito il numero di telefono del mio server con 1234 e il numero di telefono del mio cellulare con 5678, l'IP del mio server è stato sostituito con x e l'IP del mio telefono voip è stato sostituito con quello di 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"
Soluzione
Potresti voler controllare cosa dice il valore dell'intestazione di avviso. C'è un messaggio personalizzato "Il feedback rumoroso dice" ... questo è molto specifico per l'applicazione. I messaggi di timeout della richiesta vengono generalmente emulati dallo stack alla scadenza del timeout della transazione. Ciò potrebbe significare che la tua richiesta BYE a 174.37.45.134:5060 non è riuscita a raggiungere la destinazione. Questo può accadere anche quando la richiesta BYE originale non è corretta e l'altra parte la ignora.
Hai provato a eseguire il debug del tuo server localmente con SIPp ?
Puoi anche eseguire Ethereal ( Wireshark ) per controllare il tuo traffico.
Altri suggerimenti
" via_cnt == 1092 " è anche molto sospetto.
A proposito, sembra che tu stia costruendo un B2BUA, in quanto accetti la chiamata dall'esterno prima ancora di inviare un invito al telefono locale (1234). Se il telefono locale dovesse accettare con parametri diversi, accettare un codec diverso, ecc. Saresti fregato poiché hai detto al telefono locale di inviare i media direttamente al chiamante originale. Dovrebbero davvero entrambi inviare i loro media al tuo server, che inoltrerebbe (o se necessario transcodificherà).
Se non vuoi farlo (cioè non vuoi agire come relè multimediale e possibile transcodificatore), devi inoltrare INVITE al telefono locale, quindi inoltrare qualsiasi risposta, ecc. Fondamentalmente agire di più come server proxy SIP e non come SUA B2BUA.
Consiglio di verificare se call leg accetta la richiesta BYE (sembra che accetti ma ...) e come gestisce questa richiesta. Ciò di cui hai veramente bisogno è un registro simile da 174.37.45.134. Sembra che il problema sia dietro .134 (il timeout è stato generato da .134).
A proposito, come per la prima volta, vedo che stai infrangendo diverse regole di base sull'elaborazione delle chiamate che potrebbero metterti nei guai: - Manca la risposta di prova per l'origine della chiamata di origine. Se lo stack SIP del mittente attende davvero questo, ciò potrebbe portare a un ID chiamata non realmente registrato. Sì, questo è un comportamento buggy ma viviamo nel mondo reale. Gli standard dicono di rispondere con Prova al più presto (anche prima di effettuare il routing, subito dopo l'autenticazione della chiamata - Stai stabilendo una sessione di chiamata completa con la parte chiamante prima ancora di avviare INVITE in uscita per la parte chiamata. Questa è una logica sbagliata. Almeno perché in caso di mancato invio della chiamata in uscita verrà addebitato.
Se riesci a farlo rapidamente, ti consiglio di correggere prima la sequenza di impostazione delle chiamate. Avrai comunque bisogno di questo e c'è la possibilità che questo risolva la terminazione della chiamata:
INVITE ->
TRYING <-
-> INVITE
<- TRYING
<- RINGING
RINGING <-
<- OK
OK <-
ACK ->
-> ACK
Se si desidera essere conformi a RFC 3261, è obbligatorio che il "Via" le intestazioni che invii includono il ramo facoltativo (!) " " parametro.
Vedi RFC3261 ss 20.42:
Anche se questa specifica impone che sia il parametro branch presente in tutte le richieste, il BNF per il campo di intestazione indica che è facoltativo. Ciò consente l'interoperabilità con gli elementi RFC 2543, che non ha dovuto inserire il parametro branch.
RFC 3261 impone che i numeri (URI) associati nei campi Da e Da rimangano gli stessi. Se è coinvolto NAT & # 8217; gli IP possono cambiare, tuttavia i numeri devono rimanere costanti. Se noti, la & # 8216; a & # 8217; e & # 8216; da & # 8217; i campi nell'intestazione BYE vengono scambiati rendendolo un pacchetto non valido.
