[reSIProcate] Fw: CANCEL before provisional recieved.

Volodymyr.Stepanov at aricent.com Volodymyr.Stepanov at aricent.com
Fri May 4 08:26:10 CDT 2007


"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

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


More information about the resiprocate-devel mailing list