[OpenSIPS-Users] Strange retrasmission of bye messages

Fri Jan 16 11:18:49 CET 2009

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
>>>>
>>>> mmarzuola at interfree.it 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:1000 at 10.10.45.102:5060 SIP/2.0.
>>>>> Via: SIP/2.0/UDP
>>>>> 10.10.45.78:5060;rport;branch=z9hG4bK08DFC9CC7C9059DAE6CC8D4AE1FD5BB0.
>>>>> From: <sip:1003 at mysip.com>;tag=597156156.
>>>>> To: "Sjphone laptop_User"
>>>>> <sip:1000 at mysip.com>;tag=31316689311285800150.
>>>>> Contact: <sip:1003 at 10.10.45.78:5060>.
>>>>> Route: <sip:10.10.45.158;lr=on;ftag=31316689311285800150>.
>>>>> Call-ID: 8FA5A2BA-1DD2-11B2-8843-DF179CCF6174 at 10.10.45.102.
>>>>> 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:1000 at 10.10.45.102: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:1003 at mysip.com>;tag=597156156.
>>>>> To: "Sjphone laptop_User"
>>>>> <sip:1000 at mysip.com>;tag=31316689311285800150.
>>>>> Contact: <sip:1003 at 10.10.45.78:5060>.
>>>>> Call-ID: 8FA5A2BA-1DD2-11B2-8843-DF179CCF6174 at 10.10.45.102.
>>>>> 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: 8FA5A2BA-1DD2-11B2-8843-DF179CCF6174 at 10.10.45.102.
>>>>> CSeq: 25008 BYE.
>>>>> From: <sip:1003 at mysip.com>;tag=597156156.
>>>>> Server: SJphone/1.60.299a/L (SJ Labs).
>>>>> To: "Sjphone laptop_User"<sip:1000 at mysip.com>;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: 8FA5A2BA-1DD2-11B2-8843-DF179CCF6174 at 10.10.45.102.
>>>>> CSeq: 25008 BYE.
>>>>> From: <sip:1003 at mysip.com>;tag=597156156.
>>>>> Server: SJphone/1.60.299a/L (SJ Labs).
>>>>> To: "Sjphone laptop_User"<sip:1000 at mysip.com>;tag=31316689311285800150.
>>>>> .
>>>>>
>>>>> #
>>>>> U 10.10.45.158:5060 -> 10.10.45.102:5060
>>>>> BYE sip:1000 at 10.10.45.102: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:1003 at mysip.com>;tag=597156156.
>>>>> To: "Sjphone laptop_User"
>>>>> <sip:1000 at mysip.com>;tag=31316689311285800150.
>>>>> Contact: <sip:1003 at 10.10.45.78:5060>.
>>>>> Call-ID: 8FA5A2BA-1DD2-11B2-8843-DF179CCF6174 at 10.10.45.102.
>>>>> 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: 8FA5A2BA-1DD2-11B2-8843-DF179CCF6174 at 10.10.45.102.
>>>>> CSeq: 25008 BYE.
>>>>> From: <sip:1003 at mysip.com>;tag=597156156.
>>>>> Server: SJphone/1.60.299a/L (SJ Labs).
>>>>> To: "Sjphone laptop_User"<sip:1000 at mysip.com>;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
>>>>>           
>
>   