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
_______________________________________________
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
