[reSIProcate] Fw: CANCEL before provisional recieved.

[Byron Campen]

	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
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070504/3156983e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070504/3156983e/attachment.bin>