[reSIProcate] Fw: CANCEL before provisional recieved.

[Scott Godin]

FYI - DUM should be handling all of this.

 

From: resiprocate-devel-bounces at list.resiprocate.org
[mailto:resiprocate-devel-bounces at list.resiprocate.org] On Behalf Of
Byron Campen
Sent: Friday, May 04, 2007 10:44 AM
To: Volodymyr.Stepanov at aricent.com
Cc: resiprocate-devel at list.resiprocate.org
Subject: Re: [reSIProcate] Fw: CANCEL before provisional recieved.

 

          If you are going to freeze the CANCEL transaction, it needs to
be done at the TU. So, if your app decides to end a call, it needs to
put some sort of note-to-self to send a CANCEL once a provisional comes
in, and if a final response comes in, to send a BYE.

 

Best regards,

Byron Campen









Byron Campen <bcampen at estacado.net> 

04.05.2007 16:53 

To

Volodymyr.Stepanov at aricent.com 

cc

<resiprocate-devel at list.resiprocate.org> 

Subject

Re: [reSIProcate] Fw:  CANCEL before provisional recieved.

 

		




Sending a CANCEL before a provisional response is invalid behavior.
Right now, the stack forges a CANCEL/200 and sends it to the TU, but
does not allow the CANCEL to hit the wire. From here, if B never sends a
provisional, the INVITE transaction will time-out, causing the stack to
send a simulated INVITE/408. However, if B does respond, the call will
continue normally. (This is something a TU must be prepared to handle;
just because you get a CANCEL/200 doesn't mean the remote UAS will end
the INVITE transaction.) If B does send a provisional, but never sends a
final response, it is up to A to decide at what point it wishes to end
the transaction. (The TU does this by sending a CANCEL; this will cause
the stack to put a CANCEL on the wire, and start a timer that will cause
the INVITE transaction to be torn down, if it never gets a response) 

Best regards, 
Byron Campen 





Lets try again :) 
B sends provisional,but there is large time gap between A INVITEs and  B
receives this INVITE, and answers back. 
I know that sending CANCEL before provisional is incorrect. 
I trying to find "standart" solution for ,maybe, waiting for provisional
or "freeze" CANCEL transaction. 
Maybe there is another way to deal with my problem? 
Thanks.

Sorry :) 

MSN : stepanov_v_m at hotmail.com <mailto:stepanov_v_m at hotmail.com> 
ICQ : 272708933_______________________________________________
resiprocate-devel mailing list
resiprocate-devel at list.resiprocate.org
<mailto:resiprocate-devel at list.resiprocate.org> 
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
<https://list.resiprocate.org/mailman/listinfo/resiprocate-devel>  
_______________________________________________ 
resiprocate-devel mailing list 
resiprocate-devel at list.resiprocate.org 
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel 

_______________________________________________

resiprocate-devel mailing list

resiprocate-devel at list.resiprocate.org

https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070504/8de30a48/attachment.htm>