< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

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




"Scott Godin" <slgodin@xxxxxxxxxxxx>
Sent by: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx

04.05.2007 15:51

To
<Volodymyr.Stepanov@xxxxxxxxxxx>, <resiprocate-devel@xxxxxxxxxxxxxxxxxxxx>
cc
Subject
Re: [reSIProcate] CANCEL before provisional recieved.






 
From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of Volodymyr.Stepanov@xxxxxxxxxxx
Sent:
Friday, May 04, 2007 7:57 AM
To:
resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxx 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@xxxxxxxxxxx
ICQ : 272708933
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

_______________________________________________
resiprocate-devel mailing list

Attachment: smime.p7s
Description: S/MIME cryptographic signature