[reSIProcate] CANCEL before provisional recieved.

[Robert Sparks]

I think he's asking about when the INVITE transaction is in Trying -  
i.e. no response has been received yet at all.

In this case, you don't _send_ anything on the wire - you just have  
to do things in your element to clean up state.
(Basically you note that you're ready to abandon that transaction,  
wait some time (64T1 if I remember correctly) in
case a response _does_ come in and then delete things).

To be clearer - the specifications forbid actually transmitting the  
CANCEL until you are in at least the proceeding state.

RjS

On May 4, 2007, at 7:51 AM, Scott Godin wrote:

> …
>
>
>
> From: resiprocate-devel-bounces at list.resiprocate.org  
> [mailto:resiprocate-devel-bounces at list.resiprocate.org] On Behalf  
> Of Volodymyr.Stepanov at aricent.com
> Sent: Friday, May 04, 2007 7:57 AM
> To: resiprocate-devel at list.resiprocate.org
> Subject: [reSIProcate] CANCEL before provisional recieved.
>
>
>
>
> Hello!
>
> Currently i'm investigating SIP using resiprocate library.
> And i'm stuck at such problem.
> User A send INVITE to User B.
> After that A sends CANCEL and , like RFC sais i've no effect ,so  
> call remains established on the User B side.
>
> [Scott] It is unclear exactly what is happening here.  Did B send a  
> 200 response?  If B receives a CANCEL before sending a 200 then the  
> call should be cleared.
>
>
> What is the way to "fix" this problem?
> Currently if A try to send CANCEL in trying state I send BYE...Am I  
> doing right?
>
> [Scott] Not too sure what you are describing.  It is legal to send  
> a BYE after receiving a 18x response from an endpoint – this should  
> cause this leg of the call to be ended only – but the INVITE  
> transaction is still active, other potential forks can still  
> respond.  If you really want to terminate the entire call before  
> receiving a 200, you should send a CANCEL.  Note:  I’ve seen some  
> endpoints have trouble receiving a BYE in the trying state.  The  
> RFC is pretty clear on what is required on both sides for a CANCEL.
>
>
> I found couple of thougths about this problem in resiprocate-devel  
> mailing list ,but there os no specifically decision.
> Deeply appreciate for attention.
>
> Best regards,
>
> Volodymyr Stepanov
>
> A R I C E N T
>
> Kyiv, Ukraine
>
> 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

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