[reSIProcate] Fw: CANCEL before provisional recieved.

[Volodymyr.Stepanov at aricent.com]

Yes,I'm using DUM ...
Any suggestions?

Best regards,

Volodymyr Stepanov




Byron Campen <bcampen at estacado.net> 
Sent by: resiprocate-devel-bounces at list.resiprocate.org
04.05.2007 18:05

To
Volodymyr.Stepanov at aricent.com
cc
resiprocate-devel <resiprocate-devel at list.resiprocate.org>
Subject
Re: [reSIProcate] Fw:  CANCEL before provisional recieved.






Are you using DUM? I got the impression that this was not the case.

Best regards,
Byron Campen

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
ICQ : 272708933_______________________________________________
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
_______________________________________________
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/20070507/fed6cf56/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/octet-stream
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070507/fed6cf56/attachment.obj>