Hi
See line 876: Jan 14 16:32:44 [9934] DBG:tm:t_reply_matching: hash 19218 label 925515934 branch 0 Jan 14 16:32:44 [9934] DBG:tm:t_reply_matching: no matching transaction exists Jan 14 16:32:44 [9934] DBG:tm:t_reply_matching: failure to match a transaction Jan 14 16:32:44 [9934] DBG:tm:t_check: end=(nil) It looks like the 200 reply for the BYE does not match the BYE transaction....that's why the TM keep retransmitting. Regards, Bogdan Giuseppe Roberti wrote: > Hi, > maybe its my misconfiguration (or misunderstood), it resend the BYE for > every 200 Ok reply from the gateway. > I have tried to send again 200 Ok from the gateway for every received > BYE so it look like: > > 1) UAC => BYE => OPENSIPS > 2) OPENSIPS => BYE => GW > 3) GW => 200 => OPENSIPS > 4) OPENSIPS => BYE => GW > 5) GW => 200 => OPENSIPS > 6) OPENSIPS => BYE => GW > 7) GW => 200 => OPENSIPS > .. and so on .. > > The full log can be found on http://rafb.net/p/ltV7wd57.html > > Thanks. > > Bogdan-Andrei Iancu wrote: > >> Hi, >> >> if it is a single one, it may be delayed reply to the BYE request and to >> have a race between firing the first retransmission and receiving the >> reply (as maybe both events are very close in time). >> >> Do you have a trace with timestamps also? >> >> Regards, >> Bogdan >> >> Giuseppe Roberti wrote: >> >>> It happen also to me sometimes, and its a one time retransmission, but i >>> dont know why :P >>> >>> Bogdan-Andrei Iancu wrote: >>> >>> >>>> Hi Matteo, >>>> >>>> is the retransmission on time event - I mean a single retransmission >>>> ? or it keeps going? >>>> >>>> Regards, >>>> Bogdan >>>> >>>> [email protected] wrote: >>>> >>>> >>>>> Hi all. Sniffing the traffic I realized that sometimes the signaling >>>>> of BYE transaction contains replicated messages BYE. >>>>> This is an example: >>>>> >>>>> # >>>>> U 10.10.45.78:5060 -> 10.10.45.158:5060 >>>>> BYE sip:[email protected]:5060 SIP/2.0. >>>>> Via: SIP/2.0/UDP >>>>> 10.10.45.78:5060;rport;branch=z9hG4bK08DFC9CC7C9059DAE6CC8D4AE1FD5BB0. >>>>> From: <sip:[email protected]>;tag=597156156. >>>>> To: "Sjphone laptop_User" >>>>> <sip:[email protected]>;tag=31316689311285800150. >>>>> Contact: <sip:[email protected]:5060>. >>>>> Route: <sip:10.10.45.158;lr=on;ftag=31316689311285800150>. >>>>> Call-ID: [email protected]. >>>>> CSeq: 25008 BYE. >>>>> Max-Forwards: 70. >>>>> User-Agent: X-Lite release 1105d. >>>>> Content-Length: 0. >>>>> . >>>>> >>>>> # >>>>> U 10.10.45.158:5060 -> 10.10.45.102:5060 >>>>> BYE sip:[email protected]:5060 SIP/2.0. >>>>> Via: SIP/2.0/UDP 10.10.45.158;branch=z9hG4bKc2e9.5af153d5.0. >>>>> Via: SIP/2.0/UDP >>>>> 10.10.45.78:5060;received=10.10.45.78;rport=5060;branch=z9hG4bK08DFC9CC7C9059DAE6CC8D4AE1FD5BB0. >>>>> >>>>> From: <sip:[email protected]>;tag=597156156. >>>>> To: "Sjphone laptop_User" >>>>> <sip:[email protected]>;tag=31316689311285800150. >>>>> Contact: <sip:[email protected]:5060>. >>>>> Call-ID: [email protected]. >>>>> CSeq: 25008 BYE. >>>>> Max-Forwards: 69. >>>>> User-Agent: X-Lite release 1105d. >>>>> Content-Length: 0. >>>>> . >>>>> >>>>> # >>>>> U 10.10.45.102:5060 -> 10.10.45.158:5060 >>>>> SIP/2.0 200 OK. >>>>> Via: SIP/2.0/UDP >>>>> 10.10.45.158;branch=z9hG4bKc2e9.5af153d5.0,SIP/2.0/UDP >>>>> 10.10.45.78:5060;rport=5060;received=10.10.45.78;branch=z9hG4bK08DFC9CC7C9059DAE6CC8D4AE1FD5BB0. >>>>> >>>>> Content-Length: 0. >>>>> Call-ID: [email protected]. >>>>> CSeq: 25008 BYE. >>>>> From: <sip:[email protected]>;tag=597156156. >>>>> Server: SJphone/1.60.299a/L (SJ Labs). >>>>> To: "Sjphone laptop_User"<sip:[email protected]>;tag=31316689311285800150. >>>>> . >>>>> >>>>> # >>>>> U 10.10.45.158:5060 -> 10.10.45.78:5060 >>>>> SIP/2.0 200 OK. >>>>> Via: SIP/2.0/UDP >>>>> 10.10.45.78:5060;rport=5060;received=10.10.45.78;branch=z9hG4bK08DFC9CC7C9059DAE6CC8D4AE1FD5BB0. >>>>> >>>>> Content-Length: 0. >>>>> Call-ID: [email protected]. >>>>> CSeq: 25008 BYE. >>>>> From: <sip:[email protected]>;tag=597156156. >>>>> Server: SJphone/1.60.299a/L (SJ Labs). >>>>> To: "Sjphone laptop_User"<sip:[email protected]>;tag=31316689311285800150. >>>>> . >>>>> >>>>> # >>>>> U 10.10.45.158:5060 -> 10.10.45.102:5060 >>>>> BYE sip:[email protected]:5060 SIP/2.0. >>>>> Via: SIP/2.0/UDP 10.10.45.158;branch=z9hG4bKc2e9.5af153d5.0. >>>>> Via: SIP/2.0/UDP >>>>> 10.10.45.78:5060;received=10.10.45.78;rport=5060;branch=z9hG4bK08DFC9CC7C9059DAE6CC8D4AE1FD5BB0. >>>>> >>>>> From: <sip:[email protected]>;tag=597156156. >>>>> To: "Sjphone laptop_User" >>>>> <sip:[email protected]>;tag=31316689311285800150. >>>>> Contact: <sip:[email protected]:5060>. >>>>> Call-ID: [email protected]. >>>>> CSeq: 25008 BYE. >>>>> Max-Forwards: 69. >>>>> User-Agent: X-Lite release 1105d. >>>>> Content-Length: 0. >>>>> . >>>>> >>>>> # >>>>> U 10.10.45.102:5060 -> 10.10.45.158:5060 >>>>> SIP/2.0 200 OK. >>>>> Via: SIP/2.0/UDP >>>>> 10.10.45.158;branch=z9hG4bKc2e9.5af153d5.0,SIP/2.0/UDP >>>>> 10.10.45.78:5060;rport=5060;received=10.10.45.78;branch=z9hG4bK08DFC9CC7C9059DAE6CC8D4AE1FD5BB0. >>>>> >>>>> Content-Length: 0. >>>>> Call-ID: [email protected]. >>>>> CSeq: 25008 BYE. >>>>> From: <sip:[email protected]>;tag=597156156. >>>>> Server: SJphone/1.60.299a/L (SJ Labs). >>>>> To: "Sjphone laptop_User"<sip:[email protected]>;tag=31316689311285800150. >>>>> . >>>>> >>>>> I can not understand why the proxy decides to send a new bye to the >>>>> UAC despite the transaction appears to be over. >>>>> >>>>> In my system runs opensips 1.5 and mediaproxy 2.3.1. >>>>> Any idea? >>>>> >>>>> >>>>> Thanks in advance >>>>> >>>>> Marzuola Matteo >>>>> > > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
