Dear Team,We have Telematrix SIP phones with Cisco Call Manager. Telematrix phones are wrongly responding to Cancel message from Call Manager.Below is the email from Telematrix and in Black there is reply from TAC. I am wordering if you guy can help me to rectify the issue.After further analysis of the captures I have concluded that the CUCM is sending an incorrect CANCEL message and that is why it is rejected. The rejection is proper according to the RFCs. I suggest you contact Cisco regarding this problem. We will talk with our contacts at Cisco as well. The INVITE method can establish a dialog when it succeeds with a 2xx response. After a 101-199 response, an ¿early dialog¿ can be established. When an UPDATE or a CANCEL message is sent, it must be sent within the dialog (or early dialog in the case of UPDATE.) A dialog ID consists of a Call ID, a local tag and a remote tag. The local and remote tags are taken from the From and To headers of the message.
I have attached a filtered version of your capture file log1. Packet 1 is the INVITE to the TMX phone. It contains the Call ID and From tag. Packet 5 is the 180 Ringing response. It contains the To tag and establishes the ¿early dialog¿. Packet 8 is the UPDATE request to the TMX phone. You can see that it includes the Call ID, the From tag and the To tag, thus identifying the early dialog.
The CANCEL message in packet 8 contains a Call ID and From tag, but no To tag. Without the To tag, the early dialog cannot be identified and the proper response is a 481 Call Leg/Transaction Does Not Exist. See sections 9.1 and 9.2 of RFC 3261.
You may notice, as I did, that the 100 response did not contain a To tag, but the 180 response did. Section 12.1 states that only 2xx and 101-199 responses will create a dialog. Thus, this is normal.
It is likely to take a long time to get Cisco to fix this problem. Perhaps there are unapplied patches that would solve this issue. Possibly an upgrade would fix it, but that is also a big effort. Since this appears to be a bug in CANCEL, I no longer see any likelihood that a configuration change will fix it. It still might be useful to try and find one though.
Cheers, Bob
Dear Muhammed, Bob,
I have been reading in the RFC 3261 section 9.1 and I see:
The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled,
including tags. Which I can understand that the CANCEL sent by CallManager should have identical values/tags to that in the INVITE. I see that it¿s complying with the RFC and I cannot escalate the issue to change this. It must be a bug in the phone firmware.
----------------------
Thanks & Regards,
Sultan
