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

SourceForge.net noreply at sourceforge.net
Tue Jul 3 21:46:24 CEST 2007


Bugs item #1729550, was opened at 2007-06-01 12:04
Message generated for change (Comment added) made by osas
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: Closed
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: Ovidiu Sas (osas)
Date: 2007-07-03 15:46

Message:
Logged In: YES 
user_id=1395524
Originator: YES

Hi Bogdan,

There is a local 408 timeout that will close the dialog.
It will take a while, but it will be closed ... so we can keep the
existing design.
My real issue here has related to the fact that there was no callback from
the dialog module (see bug 1737524:
http://sourceforge.net/tracker/index.php?func=detail&aid=1737524&group_id=139143&atid=743020)


Regards,
Ovidiu Sas

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

Comment By: Bogdan (bogdan_iancu)
Date: 2007-07-03 07: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



More information about the Devel mailing list