[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