[OpenSER-Devel] [ openser-Bugs-1729550 ] CANCEL does not update the dialog state

[SourceForge.net]

Bugs item #1729550, was opened at 2007-06-01 19:04
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1729550&group_id=139143

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: ver 1.2.x
Status: Open
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Ovidiu Sas (osas)
>Assigned to: Bogdan (bogdan_iancu)
Summary: CANCEL does not update the dialog state

Initial Comment:
In the current implementation of the dialog module, the CANCEL method does not change the state of the dialog.

This is creating some inconsistency in the following scenario:
 - user A calls user B
 - user B sends back 180 Ringing
 - user B goes away (reboot, power cycle ...)
 - user A aborts the call and sends a CANCEL
 - since user B is no longer available, the CANCEL will time out and there will be no final reply to the initial INVITE

This will live the dialog module with a dialog in DLG_STATE_EARLY until the dialog timeout fires.


The correct behavior would be to put the dialog in a new terminated state and re-arm the dialog timeout timer to a sane value.  Like this, the dialog will be cleaned up properly and it will not be reported as "in progress".

Maybe this new state could be re-used to fix the cross over BYE (on BYE, mark the dialog as terminated and re-arm the dialog timeout timer to a sane value and absorb cross over BYEs).
see: http://sourceforge.net/tracker/index.php?func=detail&aid=1727901&group_id=139143&atid=743020


----------------------------------------------------------------------

>Comment By: Bogdan (bogdan_iancu)
Date: 2007-07-03 14:06

Message:
Logged In: YES 
user_id=1275325
Originator: NO

Hi Ovidiu,

I'm not quite convinced that only the passing CANCEL requests should alter
the dialog status. After all the CANCEL may not be delivered and or
rejected by the callee, leading to a ongoing dialog after CANCEL.
In your example, there should be a final response for the call - a local
408 timeout that will close the dialog.

Regards,
Bogdan


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1729550&group_id=139143