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@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@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
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.
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2011/5/25 Carl Wagner carl.wagner@verbalworld.com:
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 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 Wagnercarl.wagner@verbalworld.com:
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.
2011/5/26 Carl Wagner carl.wagner@verbalworld.com:
I believe you are right. I think I have found the issue in the Asterisk code.
AFAIR I reported a related bug in Asterisk tracker.
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 Wagnercarl.wagner@verbalworld.com:
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.
2011/8/9 Carl Wagner carl.wagner@verbalworld.com:
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,
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 Wagnercarl.wagner@verbalworld.com:
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)
- The Original request is the INVITE.
Right.
- Response to the original request is a 180 Ringing
Generated by the remote endpoint/UA, and NOT by the proxy!
- 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*.
2011/8/9 Carl Wagner carl.wagner@verbalworld.com:
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.
-
Carl Wagner -
Iñaki Baz Castillo -
Juha Heinanen