[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