On 29.06.10 16:28, Stefan Sayer wrote:
Hi,
if I have an outgoing call which hasn't received a reply yet, and do
dlg.bye() which yields cancel (trans_layer::cancel), then the
transaction is in TS_CALLING state - and will only be removed in trans
layer. The corresponding session stays in Disconnecting state though -
and does not end (no local FR received for the INVITE).
I think it would be better not to destroy the transaction at this place,
you're right. This way, it will time out if we never get an answer.
Also, the dialog has to detect this special case, and mark the dialog as
being canceled. Once we get any sip event for that dialog, then we can
either: send a CANCEL (for real, this time), or send a BYE.
this happens on master (don't know whether that is already different
in rco/offer_answer).
Indeed, it is different on my branch. However, it would be unwise to
port these changes to master now. It is fully untested, and does change
important parts of the state handling in the dialog...
What is the proper way to fix this? Generate a local FR when
transaction is in TS_CALLING or set dialog status to disconnected when
no reply has been received?
Wait for a timeout or any kind of response. Depending on what happened
first, the dialog needs to be properly finished:
- if it was a timeout or any error reply: no problem, everything
should work smoothly.
- if we received a positive final reply: send a BYE.
- if we received a provisionnal reply: finally send the CANCEL.
but how to determine that on dialog level? a proper new return value
of trans_layer::cancel?
This is most probably the best way right now. In my branch, the dialog
keeps a more detailed state at the beginning of the call, which allows
for the dialog to handle it all alone.
Cheers
Raphael.
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
