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?