25 May
2011
25 May
'11
12:48 a.m.
Hi,
I am having an issue getting Kamailio to properly cancel a call.
I initiate the call with an INVITE from Asterisk and then hang up.
According to rfc3665 the call flow should be:
3.8. Unsuccessful No Answer
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| 100 F3 |--------------->| INVITE F4 |
|<---------------| 100 F5 |--------------->|
| |<---------------| |
| | | 180 F6 |
| | 180 F7 |<---------------|
| 180 F8 |<---------------| |
|<---------------| | |
| CANCEL F9 | | |
|--------------->| | |
| 200 F10 | | |
|<---------------| CANCEL F11 | |
| |--------------->| |
| | 200 F12 | |
| |<---------------| |
| | | CANCEL F13 |
| | |--------------->|
| | | 200 F14 |
| | |<---------------|
| | | 487 F15 |
| | |<---------------|
| | | ACK F16 |
| | 487 F17 |--------------->|
| |<---------------| |
| | ACK F18 | |
| 487 F19 |--------------->| |
|<---------------| | |
| ACK F20 | | |
|--------------->| | |
In my case I only have one proxy - the Kamailio box, and the call is coming from Asterisk
instead of Alice.
The is the call flow that I am seeing:
Asterisk Kamailio SIP_phone
| | |
| INVITE | |
|--------------->| INVITE |
| 100 |--------------->|
|<---------------| 100 |
| |<---------------|
| | |
| | 180 |
| 180 |<---------------|
|<---------------| |
| CANCEL | |
|--------------->| |
| | CANCEL |
| |--------------->|
| 200 Canceling | |
|<---------------| |
| | 200 |
| |<---------------|
| | |
| | |
| | 487 |
| |<---------------|
| | ACK |
| 487 |--------------->|
|<---------------| |
| ACK | |
|--------------->| |
| CANCEL | |
|--------------->| |
| 200 Canceling | |
|<---------------| |
| CANCEL | |
|--------------->| |
| 200 Canceling | |
|<---------------| |
It looks like the problem is that that "200 Canceling" has a To: tag and
it shouldn't.
======================================
# cancel from Asterisk:
U 2011/05/24 15:18:56.123714 3.3.3.3:5060 -> 2.2.2.2:5060
CANCEL sip:SIP_13034445555@2.2.2.2 SIP/2.0.
Via: SIP/2.0/UDP 3.3.3.3:5060;branch=z9hG4bK51c9602a;rport.
From: "+13032223333" <sip:+13032223333@3.3.3.3>;tag=as4c415d87.
To: <sip:SIP_13034445555@2.2.2.2>.
Call-ID: 605b8de40a05924177085d71154bda77(a)3.3.3.3.
CSeq: 102 CANCEL.
User-Agent: VerbalWorld.
Max-Forwards: 70.
Content-Length: 0.
# 200 canceling from Kamailio to asterisk:
U 2011/05/24 15:18:56.127349 2.2.2.2:5060 -> 3.3.3.3:5060
SIP/2.0 200 canceling.
Via: SIP/2.0/UDP 3.3.3.3:5060;branch=z9hG4bK51c9602a;rport=5060.
From: "+13032223333" <sip:+13032223333@3.3.3.3>;tag=as4c415d87.
To: <sip:SIP_13034445555@2.2.2.2>;tag=4ed8ab9f3ed29a77613bb14b3431ff43-2f34.
Call-ID: 605b8de40a05924177085d71154bda77(a)3.3.3.3.
CSeq: 102 CANCEL.
Server: kamailio (3.1.3 (i386/linux)).
Content-Length: 0.
======================================
Why is kamialio adding a To: tag?
Portion of kamailio.cfg
=====================
...
route
{
...
route(WITHINDLG);
### only initial requests (no To: tag) from here on
if (is_method("CANCEL"))
{
if (t_check_trans())
{
xlog("L_INFO", "MAIN: Recieved Cancel, t_check_trans is
true\n");
...
t_relay();
exit;
}
...
Thanks!
Carl
25 May
25 May
9:21 a.m.
Carl Wagner writes:
It looks like the problem is that that "200
Canceling" has a To: tag and
it shouldn't.
where did you learn that?
-- juha
Regardless of the method of the original request, as long as the CANCEL
matched an existing transaction, the UAS answers the CANCEL request
itself with a 200 (OK) response. This response is constructed following
the procedures described in Section 8.2.6 noting that the To tag of the
response to the CANCEL and the To tag in the response to the original
request SHOULD be the same. The response to CANCEL is passed to the
server transaction for transmission.
8:20 p.m.
I am sorry, you are right. I was looking at rfc3665 Page 71, F10 and
it did not have a To: tag in the 200 OK to the cancel.
(I know that rfc3665 is just examples, and when in doubt I should use
rfc3261)
The last paragraph of rfc3261, section 9.2 says to use section 8.2.6 to
construct the 200 (OK).
Not sure why Asterisk is not liking the 200 Canceling.
Does anyone see anything wrong with the Cancel or the 200 Canceling in
the log below?
(I just included interactions between Asterisk and Kamailio as the other
side of Kamailio looks to be working OK)
========== Log ===========
U 2011/05/24 15:18:46.871245 asterisk_IP:5060 -> kamailio_IP:5060
INVITE sip:SIP_CalledPartyNumber@kamailio_IP SIP/2.0.
Via: SIP/2.0/UDP asterisk_IP:5060;branch=z9hG4bK51c9602a;rport.
From: "+CallingPartyNumber"
<sip:+CallingPartyNumber@asterisk_IP>;tag=as4c415d87.
To: <sip:SIP_CalledPartyNumber@kamailio_IP>.
Contact: <sip:+CallingPartyNumber@asterisk_IP>.
Call-ID: 605b8de40a05924177085d71154bda77@asterisk_IP.
CSeq: 102 INVITE.
User-Agent: Asterisk.
Max-Forwards: 70.
Date: Tue, 24 May 2011 21:18:46 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces.
Content-Type: application/sdp.
Content-Length: 238.
.
v=0.
o=root 27806 27806 IN IP4 asterisk_IP.
s=session.
c=IN IP4 asterisk_IP.
t=0 0.
m=audio 12234 RTP/AVP 0 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.
U 2011/05/24 15:18:46.874879 kamailio_IP:5060 -> asterisk_IP:5060
SIP/2.0 100 trying -- your call is important to us.
Via: SIP/2.0/UDP asterisk_IP:5060;branch=z9hG4bK51c9602a;rport=5060.
From: "+CallingPartyNumber"
<sip:+CallingPartyNumber@asterisk_IP>;tag=as4c415d87.
To: <sip:SIP_CalledPartyNumber@kamailio_IP>.
Call-ID: 605b8de40a05924177085d71154bda77@asterisk_IP.
CSeq: 102 INVITE.
Server: kamailio (3.1.3 (i386/linux)).
Content-Length: 0.
.
U 2011/05/24 15:18:47.088929 kamailio_IP:5060 -> asterisk_IP:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP asterisk_IP:5060;branch=z9hG4bK51c9602a;rport=5060.
Record-Route: <sip:kamailio_IP;lr>.
Contact:
<sip:SIP_CalledPartyNumber@2.3.4.5:21238;rinstance=ed33ca23142f2adb>.
To: <sip:SIP_CalledPartyNumber@kamailio_IP>;tag=512af75a.
From:
"+CallingPartyNumber"<sip:+CallingPartyNumber@asterisk_IP>;tag=as4c415d87.
Call-ID: 605b8de40a05924177085d71154bda77@asterisk_IP.
CSeq: 102 INVITE.
User-Agent: X-Lite release 1104o stamp 56125.
Content-Length: 0.
.
U 2011/05/24 15:18:56.123714 asterisk_IP:5060 -> kamailio_IP:5060
CANCEL sip:SIP_CalledPartyNumber@kamailio_IP SIP/2.0.
Via: SIP/2.0/UDP asterisk_IP:5060;branch=z9hG4bK51c9602a;rport.
From: "+CallingPartyNumber"
<sip:+CallingPartyNumber@asterisk_IP>;tag=as4c415d87.
To: <sip:SIP_CalledPartyNumber@kamailio_IP>.
Call-ID: 605b8de40a05924177085d71154bda77@asterisk_IP.
CSeq: 102 CANCEL.
User-Agent: Asterisk.
Max-Forwards: 70.
Content-Length: 0.
.
U 2011/05/24 15:18:56.127349 kamailio_IP:5060 -> asterisk_IP:5060
SIP/2.0 200 canceling.
Via: SIP/2.0/UDP asterisk_IP:5060;branch=z9hG4bK51c9602a;rport=5060.
From: "+CallingPartyNumber"
<sip:+CallingPartyNumber@asterisk_IP>;tag=as4c415d87.
To:
<sip:SIP_CalledPartyNumber@kamailio_IP>;tag=4ed8ab9f3ed29a77613bb14b3431ff43-2f34.
Call-ID: 605b8de40a05924177085d71154bda77@asterisk_IP.
CSeq: 102 CANCEL.
Server: kamailio (3.1.3 (i386/linux)).
Content-Length: 0.
.
U 2011/05/24 15:18:56.310422 kamailio_IP:5060 -> asterisk_IP:5060
SIP/2.0 487 Request Terminated.
Via: SIP/2.0/UDP asterisk_IP:5060;branch=z9hG4bK51c9602a;rport=5060.
To: <sip:SIP_CalledPartyNumber@kamailio_IP>;tag=512af75a.
From:
"+CallingPartyNumber"<sip:+CallingPartyNumber@asterisk_IP>;tag=as4c415d87.
Call-ID: 605b8de40a05924177085d71154bda77@asterisk_IP.
CSeq: 102 INVITE.
User-Agent: X-Lite release 1104o stamp 56125.
Content-Length: 0.
.
U 2011/05/24 15:18:56.311992 asterisk_IP:5060 -> kamailio_IP:5060
ACK sip:SIP_CalledPartyNumber@kamailio_IP SIP/2.0.
Via: SIP/2.0/UDP asterisk_IP:5060;branch=z9hG4bK51c9602a;rport.
From: "+CallingPartyNumber"
<sip:+CallingPartyNumber@asterisk_IP>;tag=as4c415d87.
To: <sip:SIP_CalledPartyNumber@kamailio_IP>;tag=512af75a.
Contact: <sip:+CallingPartyNumber@asterisk_IP>.
Call-ID: 605b8de40a05924177085d71154bda77@asterisk_IP.
CSeq: 102 ACK.
User-Agent: Asterisk.
Max-Forwards: 70.
Content-Length: 0.
.
U 2011/05/24 15:18:57.134340 asterisk_IP:5060 -> kamailio_IP:5060
CANCEL sip:SIP_CalledPartyNumber@kamailio_IP SIP/2.0.
Via: SIP/2.0/UDP asterisk_IP:5060;branch=z9hG4bK51c9602a;rport.
From: "+CallingPartyNumber"
<sip:+CallingPartyNumber@asterisk_IP>;tag=as4c415d87.
To: <sip:SIP_CalledPartyNumber@kamailio_IP>.
Call-ID: 605b8de40a05924177085d71154bda77@asterisk_IP.
CSeq: 102 CANCEL.
User-Agent: Asterisk.
Max-Forwards: 70.
Content-Length: 0.
.
U 2011/05/24 15:18:57.136940 kamailio_IP:5060 -> asterisk_IP:5060
SIP/2.0 200 canceling.
Via: SIP/2.0/UDP asterisk_IP:5060;branch=z9hG4bK51c9602a;rport=5060.
From: "+CallingPartyNumber"
<sip:+CallingPartyNumber@asterisk_IP>;tag=as4c415d87.
To:
<sip:SIP_CalledPartyNumber@kamailio_IP>;tag=4ed8ab9f3ed29a77613bb14b3431ff43-2f34.
Call-ID: 605b8de40a05924177085d71154bda77@asterisk_IP.
CSeq: 102 CANCEL.
Server: kamailio (3.1.3 (i386/linux)).
Content-Length: 0.
.
U 2011/05/24 15:18:58.123319 asterisk_IP:5060 -> kamailio_IP:5060
CANCEL sip:SIP_CalledPartyNumber@kamailio_IP SIP/2.0.
Via: SIP/2.0/UDP asterisk_IP:5060;branch=z9hG4bK51c9602a;rport.
From: "+CallingPartyNumber"
<sip:+CallingPartyNumber@asterisk_IP>;tag=as4c415d87.
To: <sip:SIP_CalledPartyNumber@kamailio_IP>.
Call-ID: 605b8de40a05924177085d71154bda77@asterisk_IP.
CSeq: 102 CANCEL.
User-Agent: Asterisk.
Max-Forwards: 70.
Content-Length: 0.
.
U 2011/05/24 15:18:58.125872 kamailio_IP:5060 -> asterisk_IP:5060
SIP/2.0 200 canceling.
Via: SIP/2.0/UDP asterisk_IP:5060;branch=z9hG4bK51c9602a;rport=5060.
From: "+CallingPartyNumber"
<sip:+CallingPartyNumber@asterisk_IP>;tag=as4c415d87.
To:
<sip:SIP_CalledPartyNumber@kamailio_IP>;tag=4ed8ab9f3ed29a77613bb14b3431ff43-2f34.
Call-ID: 605b8de40a05924177085d71154bda77@asterisk_IP.
CSeq: 102 CANCEL.
Server: kamailio (3.1.3 (i386/linux)).
Content-Length: 0.
On 05/25/2011 12:21 AM, Juha Heinanen wrote:
Carl Wagner writes:
It looks like the problem is that that "200
Canceling" has a To: tag and
it shouldn't.
where did you learn that?
-- juha
Regardless of the method of the original request, as long as the CANCEL
matched an existing transaction, the UAS answers the CANCEL request
itself with a 200 (OK) response. This response is constructed following
the procedures described in Section 8.2.6 noting that the To tag of the
response to the CANCEL and the To tag in the response to the original
request SHOULD be the same. The response to CANCEL is passed to the
server transaction for transmission.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
10:01 p.m.
2011/5/25 Carl Wagner <carl.wagner(a)verbalworld.com>om>:
I am sorry, you are right. I was looking at rfc3665
Page 71, F10 and it
did not have a To: tag in the 200 OK to the cancel.
(I know that rfc3665 is just examples, and when in doubt I should use
rfc3261)
The last paragraph of rfc3261, section 9.2 says to use section 8.2.6 to
construct the 200 (OK).
Not sure why Asterisk is not liking the 200 Canceling.
Does anyone see anything wrong with the Cancel or the 200 Canceling in the
log below?
Because Asterisk is buggy and expects (wrongly) that the Totag of the
CANCEL must match the Totag of a previously received 1XX response.
This is of course a wrong assumption as there could be diferent 1XX
responses with different Totag (when forking).
I remember that it just occurs if you set Asterisk sip.conf with
pendantic-mode enabled.
Asterisk is buggy.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
26 May
26 May
5:36 p.m.
I believe you are right. I think I have found the issue in the Asterisk
code.
Thanks!
Carl
On 05/25/2011 01:01 PM, Iñaki Baz Castillo wrote:
2011/5/25 Carl
Wagner<carl.wagner(a)verbalworld.com>om>:
I am sorry, you are right. I was looking at
rfc3665 Page 71, F10 and it
did not have a To: tag in the 200 OK to the cancel.
(I know that rfc3665 is just examples, and when in doubt I should use
rfc3261)
The last paragraph of rfc3261, section 9.2 says to use section 8.2.6 to
construct the 200 (OK).
Not sure why Asterisk is not liking the 200 Canceling.
Does anyone see anything wrong with the Cancel or the 200 Canceling in the
log below?
Because Asterisk is buggy and expects (wrongly) that the Totag of the
CANCEL must match the Totag of a previously received 1XX response.
This is of course a wrong assumption as there could be diferent 1XX
responses with different Totag (when forking).
I remember that it just occurs if you set Asterisk sip.conf with
pendantic-mode enabled.
Asterisk is buggy.
9 Aug
9 Aug
2:47 a.m.
Hi,
I was looking at the 3261 again and have a question.
16.10 CANCEL Processing (Proxy Behavior)
... If a matching response context is found, the element MUST
immediately return a 200 (OK) response to the CANCEL request. In
this case, the element is acting as a user agent server as defined in
Section 8.2. ...
So Kamailio is acting as a UAS when it receives a CANCEL
We will assume for now that Asterisk properly constructed the CANCEL.
9.2 Server Behavior (Canceling a Request)
...
Regardless of the method of the original request, as long as the
CANCEL matched an existing transaction, the UAS answers the CANCEL
request itself with a 200 (OK) response. This response is
constructed following the procedures described in Section 8.2.6
noting that*the To tag of the response to the CANCEL and the To tag
in the response to the original request SHOULD be the same.* ...
By my reading of 9.2, the portion about the To tag,
(In my case)
1) The Original request is the INVITE.
2) Response to the original request is a 180 Ringing
3) Response to the CANCEL is a 200 OK
Therefore the To tag in the 180 Ringing must match the To tag in the 200 OK?
Is this right?
When 3261 says "the response to the original request" is that the last
response?
Relevant portions of the log:
SIP/2.0 180 Ringing. ...
To: <sip:SIP_CalledPartyNumber@kamailio_IP>;tag=512af75a.
SIP/2.0 200 canceling. ...
To:
<sip:SIP_CalledPartyNumber@kamailio_IP>;tag=4ed8ab9f3ed29a77613bb14b3431ff43-2f34.
Not sure how this work with forking.
So to my eyes, this looks like a Kamailio bug?
Please tell me where I went wrong.
FYI in Asterisk it is dependent on the pedanticsipchecking being enabled.
This is set in sip.conf: pedantic=yes
Thanks,
Carl
On 05/25/2011 01:01 PM, Iñaki Baz Castillo wrote:
2011/5/25 Carl
Wagner<carl.wagner(a)verbalworld.com>om>:
I am sorry, you are right. I was looking at
rfc3665 Page 71, F10 and it
did not have a To: tag in the 200 OK to the cancel.
(I know that rfc3665 is just examples, and when in doubt I should use
rfc3261)
The last paragraph of rfc3261, section 9.2 says to use section 8.2.6 to
construct the 200 (OK).
Not sure why Asterisk is not liking the 200 Canceling.
Does anyone see anything wrong with the Cancel or the 200 Canceling in the
log below?
Because Asterisk is buggy and expects (wrongly) that the Totag of the
CANCEL must match the Totag of a previously received 1XX response.
This is of course a wrong assumption as there could be diferent 1XX
responses with different Totag (when forking).
I remember that it just occurs if you set Asterisk sip.conf with
pendantic-mode enabled.
Asterisk is buggy.
11:33 a.m.
2011/8/9 Carl Wagner <carl.wagner(a)verbalworld.com>om>:
Hi,
I was looking at the 3261 again and have a question.
16.10 CANCEL Processing (Proxy Behavior)
... If a matching response context is found, the element MUST
immediately return a 200 (OK) response to the CANCEL request. In
this case, the element is acting as a user agent server as defined in
Section 8.2. ...
So Kamailio is acting as a UAS when it receives a CANCEL
But it's still a proxy, and Kamailio has NOT previously generated
*byitself* provisional non-100 responses for the UAC.
We will assume for now that Asterisk properly
constructed the CANCEL.
9.2 Server Behavior (Canceling a Request)
...
Regardless of the method of the original request, as long as the
CANCEL matched an existing transaction, the UAS answers the CANCEL
request itself with a 200 (OK) response. This response is
constructed following the procedures described in Section 8.2.6
noting that the To tag of the response to the CANCEL and the To tag
in the response to the original request SHOULD be the same. ...
Who did construct the response (i.e. 180 Ringing) for the original
request? the proxy? or the UA in the other side?
This section 9.2 is just talking about the dialog endpoints, not about
a proxy. Again: a proxy has NOT generated any response for the
original request (INVITE), but just the mandatory 100 Trying.
By my reading of 9.2, the portion about the To tag,
(In my case)
1) The Original request is the INVITE.
Right.
2) Response to the original request is a 180 Ringing
Generated by the remote endpoint/UA, and NOT by the proxy!
3) Response to the CANCEL is a 200 OK
Therefore the To tag in the 180 Ringing must match the To tag in the 200 OK?
Is this right?
No. More comments below.
When 3261 says "the response to the original
request" is that the last
response?
Not at all. CANCEL is hop-by-hop. Let's shwo an example with parallel forking:
Alice Proxy Bob1 Bob2
INVITE --------------------->
INVITE ----------->
INVITE
------------------------------------>
<---- 180 (Totag A)
<----------------------------- 180 (Totag B)
<----------- 180 (Totag A)
<----------- 180 (Totag B)
CANCEL -------------------->
<------------ 200 (Totag P)
CANCEL ---------->
<--- 200 (Totag A)
CANCEL
-------------------------------------->
<-------------------------------
200 (Totag B)
<--- 487 (Totag A)
ACK ----------------->
<-------------------------------
487 (Totag B)
ACK
-------------------------------------------->
<--------------- 487 (Totag A)
ACK ---------------------------->
As you can see, when a real UAS (Bob1 and Bob2) receives a CANCEL
(from the proxy) the Totag of the 200 for that CANCEL MUST have same
Totag as the provisional non-100 responses sent by same UAS to the
original request (INVITE). So Bob1 replies "200 Cancelled" with Totag
A and Bob2 with Totag B.
But the proxy is not a UAS, it has not generated a provisional non-100
response for the INVITE (but just forwarded them upstream) so when a
proxy receives a CANCEL it sets a random Totag (P in the example
above) in the "200 Cancelled". That's all.
Later it occurs that the proxy *generates* a CANCEL for each pending
branch (Bob1 and Bob2) and receives two 487 (for terminating the
INVITE transaction). As a proxy, it chooses one of them (in the
example above it chooses the first one coming from Bob1) and forwards
the winning reply to the UAC. Of course, such winning reply has a
Totag (A) different than the Totag P the proxy replied in the "200
Cancelled". How could be the same?? it's not possible, the proxy MUST
reply "200 Cancelled" before habing a winning reply for the INVITE
transaction!
Hope it's clear now.
Relevant portions of the log:
SIP/2.0 180 Ringing. ...
To: <sip:SIP_CalledPartyNumber@kamailio_IP>;tag=512af75a.
SIP/2.0 200 canceling. ...
To:
<sip:SIP_CalledPartyNumber@kamailio_IP>;tag=4ed8ab9f3ed29a77613bb14b3431ff43-2f34.
Not sure how this work with forking.
Because it's correct. Please don't waste more time thinking that what
you say above is correct, this topic has been heavily discussed and
explained in some lists like sip-implementors.
So to my eyes, this looks like a Kamailio bug?
It's NOT a bug. It's the correct behaviour.
Please tell me where I went wrong.
I hope the explanation with the example helps you.
Regards.
FYI in Asterisk it is dependent on the
pedanticsipchecking being enabled.
This is set in sip.conf: pedantic=yes
Right. If pedantic=yes, then Asterisk assumes the same wrong concept
you have understood and fails to match a 200 "Cancelled" with
different Totag (when coming from a proxy). It's a bug in *Asterisk*.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
10:33 p.m.
Iñaki,
Thank you. Nice explanation.
I plan to open a bug on this with Asterisk. Are there any RFC
section(s) that I can reference, in case they interpret 3261 the same
way I did?
Thanks,
Carl
On 08/09/2011 02:33 AM, Iñaki Baz Castillo wrote:
2011/8/9 Carl
Wagner<carl.wagner(a)verbalworld.com>om>:
Hi,
I was looking at the 3261 again and have a question.
16.10 CANCEL Processing (Proxy Behavior)
... If a matching response context is found, the element MUST
immediately return a 200 (OK) response to the CANCEL request. In
this case, the element is acting as a user agent server as defined in
Section 8.2. ...
So Kamailio is acting as a UAS when it receives a CANCEL
But it's still a
proxy, and Kamailio has NOT previously generated
*byitself* provisional non-100 responses for the UAC.
We will assume for now that Asterisk properly
constructed the CANCEL.
9.2 Server Behavior (Canceling a Request)
...
Regardless of the method of the original request, as long as the
CANCEL matched an existing transaction, the UAS answers the CANCEL
request itself with a 200 (OK) response. This response is
constructed following the procedures described in Section 8.2.6
noting that the To tag of the response to the CANCEL and the To tag
in the response to the original request SHOULD be the same. ...
Who did
construct the response (i.e. 180 Ringing) for the original
request? the proxy? or the UA in the other side?
This section 9.2 is just talking about the dialog endpoints, not about
a proxy. Again: a proxy has NOT generated any response for the
original request (INVITE), but just the mandatory 100 Trying.
By my reading of 9.2, the portion about the To
tag,
(In my case)
1) The Original request is the INVITE.
Right.
2) Response to the original request is a 180
Ringing
Generated by the remote endpoint/UA, and NOT by the proxy!
3) Response to the CANCEL is a 200 OK
Therefore the To tag in the 180 Ringing must match the To tag in the 200 OK?
Is this right?
No. More comments below.
When 3261 says "the response to the original
request" is that the last
response?
Not at all. CANCEL is hop-by-hop. Let's shwo an example with
parallel forking:
Alice Proxy Bob1 Bob2
INVITE --------------------->
INVITE ----------->
INVITE
------------------------------------>
<---- 180 (Totag A)
<----------------------------- 180 (Totag B)
<----------- 180 (Totag A)
<----------- 180 (Totag B)
CANCEL -------------------->
<------------ 200 (Totag P)
CANCEL ---------->
<--- 200 (Totag A)
CANCEL
-------------------------------------->
<-------------------------------
200 (Totag B)
<--- 487 (Totag A)
ACK ----------------->
<-------------------------------
487 (Totag B)
ACK
-------------------------------------------->
<--------------- 487 (Totag A)
ACK ---------------------------->
As you can see, when a real UAS (Bob1 and Bob2) receives a CANCEL
(from the proxy) the Totag of the 200 for that CANCEL MUST have same
Totag as the provisional non-100 responses sent by same UAS to the
original request (INVITE). So Bob1 replies "200 Cancelled" with Totag
A and Bob2 with Totag B.
But the proxy is not a UAS, it has not generated a provisional non-100
response for the INVITE (but just forwarded them upstream) so when a
proxy receives a CANCEL it sets a random Totag (P in the example
above) in the "200 Cancelled". That's all.
Later it occurs that the proxy *generates* a CANCEL for each pending
branch (Bob1 and Bob2) and receives two 487 (for terminating the
INVITE transaction). As a proxy, it chooses one of them (in the
example above it chooses the first one coming from Bob1) and forwards
the winning reply to the UAC. Of course, such winning reply has a
Totag (A) different than the Totag P the proxy replied in the "200
Cancelled". How could be the same?? it's not possible, the proxy MUST
reply "200 Cancelled" before habing a winning reply for the INVITE
transaction!
Hope it's clear now.
Relevant portions of the log:
SIP/2.0 180 Ringing. ...
To:<sip:SIP_CalledPartyNumber@kamailio_IP>;tag=512af75a.
SIP/2.0 200 canceling. ...
To:
<sip:SIP_CalledPartyNumber@kamailio_IP>;tag=4ed8ab9f3ed29a77613bb14b3431ff43-2f34.
Not sure how this work with forking.
Because it's correct. Please don't
waste more time thinking that what
you say above is correct, this topic has been heavily discussed and
explained in some lists like sip-implementors.
So to my eyes, this looks like a Kamailio bug?
It's NOT a bug. It's the correct behaviour.
Please tell me where I went wrong.
I hope
the explanation with the example helps you.
Regards.
FYI in Asterisk it is dependent on the
pedanticsipchecking being enabled.
This is set in sip.conf: pedantic=yes
Right. If pedantic=yes, then Asterisk
assumes the same wrong concept
you have understood and fails to match a 200 "Cancelled" with
different Totag (when coming from a proxy). It's a bug in *Asterisk*.
11:16 p.m.
2011/8/9 Carl Wagner <carl.wagner(a)verbalworld.com>om>:
Iñaki,
Thank you. Nice explanation.
I plan to open a bug on this with Asterisk. Are there any RFC section(s)
that I can reference, in case they interpret 3261 the same way I did?
Hi Carl, AFAIR the bug is already (somehow) reported in Asterisk (not
sure however).
I don't remember where exactly what I've explained is defined in the
RFC, but for sure in the CANCEL section. Please let me know when you
report the issue in Asterisk so I can participate in it.
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
4854
days inactive
4931
days old
9 comments
3 participants
participants (3)
-
Carl Wagner -
Iñaki Baz Castillo -
Juha Heinanen