[reSIProcate] Fw: CANCEL before provisional recieved.

[Byron Campen]

	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

>
>
>
> "Scott Godin" <slgodin at icescape.com>
> Sent by: resiprocate-devel-bounces at list.resiprocate.org
> 04.05.2007 15:51
>
> To
> <Volodymyr.Stepanov at aricent.com>, <resiprocate- 
> devel at list.resiprocate.org>
> cc
> Subject
> Re: [reSIProcate] CANCEL before provisional recieved.
>
>
>
>
>
> …
>
> 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.
>
>
>
> // 
> ********************************************************************** 
> ********************************/
>
> Ok :)
> Try to explain my problem.
> Main issue is when user A tries to send CANCEL just after INVITE,  
> so no answers from B side recieved .
> In logs I have lines .
>
> DEBUG | 20070504-161143.776 | PortalAgent | RESIP:TRANSPORT | 1644  
> | Transport.cxx:258 | incoming from: [ V4 10.15.3.7:5060 UDP target  
> domain=unspecified received on: Transport: [ V4 10.15.8.37:5080 UDP  
> target domain=unspecified connectionId=0 ] on 10.15.8.37  
> connectionId=0 ]
> WARNING | 20070504-161143.776 | PortalAgent | RESIP:TRANSACTION |  
> 1644 | TransactionState.cxx:423 | You can't CANCEL a request until  
> a provisional has been received
> DEBUG | 20070504-161143.776 | PortalAgent | RESIP | 1644 |  
> Helper.cxx:302 | Helper::makeResponse(SipReq:  CANCEL admin/ 
> unittest3 at 10.15.3.7 tid=f179f93ee801be35 cseq=CANCEL / 1 from(tu)  
> code=200 reason=
> DEBUG | 20070504-161143.776 | PortalAgent | RESIP:TRANSACTION |  
> 1644 | TransactionState.cxx:1721 | Send to TU: TU:  
> DialogUsageManager size=0 SIP/2.0 200 OK
>
> On A side call hanged, but B remains  in the dark about this fact
>
> I understand ,that stack works like said in RFC, but what should I  
> do to prevent wrong call state on the B side?
>
>
> Thanks for patience :)
>
>
> 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
> _______________________________________________
> 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/6c44fd87/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/6c44fd87/attachment.bin>