[OpenSIPS-Users] dialog bye_on_timeout and other issues

[Bogdan-Andrei Iancu]

Hi Alex,

First, about the Route hdr - opensips adds a Route hdr in BYE only if 
the dialog (on that specific leg) received a 200 OK INVITE with RR 
header - can you confirm this at (1) signalling level and (2) at dialog 
level (do a dlg_list via MI).

Now, about the bogus BYE - indeed, it is strange - do you use a local 
route for accessing the BYEs requests? Attached is a small debugging 
patch - please apply it a nd see if you get any WARNINGs at runtime.

Regards,
Bogdan

-- 
Bogdan-Andrei Iancu
OpenSIPS Bootcamp
20 - 24 September 2010, Frankfurt, Germany
www.voice-system.ro



Alex Massover wrote:
>
> Hi,
>
> I have a strange behavior of OpenSIPS 1.6.2. First dialog module 
> _/sometimes/_ sends a wrong bye (generated by dialog module on timeout):
>
> Here’s a correct one:
>
> BYE sip:972123456789 at 212.179.159.9:7640;transport=UDP SIP/2.0
>
> Via: SIP/2.0/UDP 212.179.159.18;branch=z9hG4bKd6c7.7f7a3d36.0
>
> To: <sip:+496925420990 at 212.179.159.18:5060>;tag=8548
>
> From: <sip:+972542384166 at 212.179.159.9:5061>;tag=8547
>
> CSeq: 2 BYE
>
> Call-ID: 8547-15512 at 212.179.159.9
>
> Content-Length: 0
>
> Max-Forwards: 70
>
> And here’s a wrong one:
>
> BYE sip:212.179.159.9:7640 SIP/2.0
>
> Via: SIP/2.0/UDP 212.179.159.18;branch=z9hG4bKc6c7.7ecb1057.0
>
> To: <sip:+496925420989 at 212.179.159.18:5060>;tag=8547
>
> From: <sip:+972542384166 at 212.179.159.9:5061>;tag=8546
>
> CSeq: 2 BYE
>
> Call-ID: 8546-15512 at 212.179.159.9
>
> Route: <sip:972123456789 at 212.179.159.9:7640;transport=UDP>
>
> Content-Length: 0
>
> Max-Forwards
>
> In a wrong one there’s Route header inserted (by mistake?) and the 
> message is cut at Max-Forwards line. It’s missing “:70\r\n”.
>
> Both of the BYEs above I got just by running test with SIPP. This can 
> happen even with single call, not related to stress. I.e. one call it 
> might send a correct BYE and another call a corrupted BYE, without any 
> reason, because calls are exactly the same.
>
> Another issue is, looks like t_newtran() is unable to handle 
> retransmissions. In this test UAC and UAS are in the same machine 
> (.9), and you can’t see INVITE from OpenSIPS (.18) to UAS because it’s 
> fragmented.
>
> |Time | x.x.x.9 | x.x.x.18 |
>
> |13.501 | INVITE SDP ( MP4V-ES) |SIP From: 
> sip:+xxxxxxxxx166 at x.x.x.9:5061 To:sip:+xxxxxxxxxx82 at x.x.x.18:5060
>
> | |(5061) ------------------> (5060) |
>
> |14.003 | INVITE SDP ( MP4V-ES) |SIP From: 
> sip:+xxxxxxxxx166 at x.x.x.9:5061 To:sip:+xxxxxxxxxx82 at x.x.x.18:5060
>
> | |(5061) ------------------> (5060) |
>
> |15.005 | INVITE SDP ( MP4V-ES) |SIP From: 
> sip:+xxxxxxxxx166 at x.x.x.9:5061 To:sip:+xxxxxxxxxx82 at x.x.x.18:5060
>
> | |(5061) ------------------> (5060) |
>
> |15.743 | 100 Trying| |SIP Status
>
> | |(5061) <------------------ (5060) |
>
> |15.800 | 181 Call is being forwarded |SIP Status
>
> | |(5061) <------------------ (5060) |
>
> |15.801 | 100 Trying| |SIP Status
>
> | |(7640) ------------------> (5060) |
>
> |15.801 | 180 Ringing |SIP Status
>
> | |(7640) ------------------> (5060) |
>
> |15.801 | 200 OK SDP ( G723) |SIP Status
>
> | |(7640) ------------------> (5060) |
>
> |15.840 | 181 Call is being forwarded |SIP Status
>
> | |(5061) <------------------ (5060) |
>
> |16.041 | 181 Call is being forwarded |SIP Status
>
> | |(5061) <------------------ (5060) |
>
> |16.188 | 180 Ringing |SIP Status
>
> | |(5061) <------------------ (5060) |
>
> |16.188 | 200 OK SDP ( G723) |SIP Status
>
> | |(5061) <------------------ (5060) |
>
> |16.189 | ACK | |SIP Request
>
> | |(5061) ------------------> (5060) |
>
> |16.302 | 200 OK SDP ( G723) |SIP Status
>
> | |(7640) ------------------> (5060) |
>
> |16.357 | ACK | |SIP Request
>
> | |(7640) <------------------ (5060) |
>
> |16.651 | 200 OK SDP ( G723) |SIP Status
>
> | |(5061) <------------------ (5060) |
>
> |16.652 | ACK | |SIP Request
>
> | |(5061) ------------------> (5060) |
>
> |17.075 | ACK | |SIP Request
>
> | |(7640) <------------------ (5060) |
>
> |36.730 | BYE | |SIP Request
>
> | |(5061) <------------------ (5060) |
>
> |36.731 | BYE | |SIP Request
>
> | |(7640) <------------------ (5060) |
>
> |36.731 | 200 OK | |SIP Status
>
> | |(5061) ------------------> (5060) |
>
> |36.731 | 200 OK | |SIP Status
>
> | |(7640) ------------------> (5060) |
>
> This issue happens during stress test.
>
> Any ideas, please? The OpenSIPS 1.6.2 is compiled with system malloc 
> and runs over VMware.
>
> --
>
> Best Regards,
>
> Alex Massover
>
>
>
> This mail was sent via Mail-SeCure System.
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dialog.patch
Type: text/x-diff
Size: 450 bytes
Desc: not available
Url : http://lists.opensips.org/pipermail/users/attachments/20100621/393a2830/attachment.patch