#253 stale dialog after using call hold

1.5.x
closed-invalid
modules (454)
3
2010-02-09
2010-01-26
No

I've found that if I call the other SIP account, put the call on and off hold (necessarily as a caller - if callee uses call hold this doesn't happen) and then end the call, OpenSIPS keeps thinking this is an active dialog and it just hangs there forever. I am attaching the tcpdump trace of just one problematic call made right on the opensips server and the opensips.log with debug level 3 (it's useful only in the sense that it shows there were no errors in dialog module, but if in increase debug level to 4 there are tons of useless info). This is the output of profile_list_dlgs command obtained after the call was ended.

# opensipsctl fifo profile_list_dlgs caller
dialog:: hash=3718:1395615021
state:: 4
user_flags:: 0
timestart:: 1264533523
timeout:: 60019
callid:: ZTkwOGQxYjdlZGYwMDljODE1ODQ3MmRmY2I5MjI0YzM.
from_uri:: sip:000100@68.166.6.122
from_tag:: ae344d3e
caller_contact:: sip:000100@77.122.227.73:6370
caller_cseq:: 3
caller_route_set::
caller_bind_addr:: udp:68.166.6.122:5060
to_uri:: sip:000101@68.166.6.122
to_tag:: 2135014f
callee_contact:: sip:000101@77.122.227.73:27436;rinstance=8c6d4f852faa42eb
callee_cseq:: 2
callee_route_set::
callee_bind_addr:: udp:68.166.6.122:5060

Discussion

  •  
    Attachments
  • this is opensips log for this call

     
    Attachments
  • I'm attaching below one the opensips log for another call, this time with debug=4.

    This is the stale dialog after after the call end:
    dialog:: hash=3558:842134357
    state:: 4
    user_flags:: 0
    timestart:: 1264534993
    timeout:: 61487
    callid:: YTQ3YjRjNTVjYWQwYWRmOTQ5ZDE3MmZjOTlhMGIyY2M.
    from_uri:: sip:000100@68.166.6.122
    from_tag:: 9673d152
    caller_contact:: sip:000100@77.122.227.73:6370
    caller_cseq:: 3
    caller_route_set::
    caller_bind_addr:: udp:68.166.6.122:5060
    to_uri:: sip:000101@68.166.6.122
    to_tag:: b542cf1c
    callee_contact:: sip:000101@77.122.227.73:27436;rinstance=8c6d4f852faa42eb
    callee_cseq:: 2
    callee_route_set::
    callee_bind_addr:: udp:68.166.6.122:5060

     
  • log with debug=4

     
    Attachments
  • Oh and I'm using version 1.5.3
    As for configuration script, I'm doing basically create_dialog() and then set_dlg_profile() to insert dialog onto caller profile.

     
    • assigned_to: nobody --> bogdan_iancu
     
  • Hi Andrew,

    I looked over the debug logs and it seams to me that it is a client bug. The dialog module sets a "did" param in RR header -> this RR info is persistent across all call, they are not to be changed or re-learned by any other request within the dialog.
    What happens in your case is that the first re-INVITE is collecting a new set of RR (you probably do record-route() for sequential requests also) -> this new RR does not have a did param ( as the dialog module does not set it) and the client (against RFC) re-learns the RR set from re-INVITE (instead of keep using the RR set that was collected by the original INVITE). Once the did param was lost, the following requests do not match anymore the dialog, so the BYE is lost.

    So, the bug is that your client re-learns the RR ser during the dialog. To avoid this, try not to do record_route() for sequential requests.

    Regards,
    Bogdan

     
    • priority: 5 --> 3
    • status: open --> open-invalid
     
    • status: open-invalid --> closed-invalid
     
  • Thank you very much Bogdan - that explains it!