07-04-2014 09:33 AM - edited 03-16-2019 11:18 PM
Hello!
Hello - I am facing below issue, can you please some idea to solve the issue
The call flow
isp -->sip trunk --> gw --> cucm --> ip phone
When I calling from pstn and hung up
When incoming call is initiated and outside user then hang up without answering, phone will not stop ringing. The provider send me a Cancel request but then GW give me 481 Call Leg/Transaction Does Not Exist.
debug in attachment.
Thank you in advance!
-Denis
Solved! Go to Solution.
07-07-2014 03:06 AM
Hi Denis,
They should care about the RFC3261. I think Manish is right. In their cancel message they put the wrong request URI. Check the section '9.1 Client Behavior' in the RFC they talk about
http://www.ietf.org/rfc/rfc3261.txt
I copy here
A CANCEL request SHOULD NOT be sent to cancel a request other than INVITE. Since requests other than INVITE are responded to immediately, sending a CANCEL for a non-INVITE request would always create a race condition.
The following procedures are used to construct a CANCEL request. 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.
If you check the sentence in bold you will see that the Request-URI should be identical with that of the INVITE (along with the other headers the RFC mentions)
So you probably need to get back to your provider and tell them to fix that according to the rfc they pointed at :)
Regards
07-05-2014 02:01 AM
Hi Denis,
The only thing looks wired in CANCEL message is the R-URI header. It should be based on the initial INVITE message uri sent by ISP to GW.
CANCEL sip:00095701@192.168.100.166:5060 SIP/2.0
CANCEL sip:2105981@192.168.100.166:5060 SIP/2.0
You may get intouch with your provider and ask them to send CANCEL message URI based on "To" header rather than "Contact" header . Because "CANCEL" is not sent between end points like the "BYE" message.
Thanks
Manish
07-07-2014 02:27 AM
Hi Manish,
Thank you very much for your reply!
I contacted with isp they told me that they based on "Contact" header which they receive from GW and they don't care what in "To" header according to RFC 3261.
Tried to find it in RFC, but I can't find where this defined explicitly.
Thank you!
-Denis
07-07-2014 03:06 AM
Hi Denis,
They should care about the RFC3261. I think Manish is right. In their cancel message they put the wrong request URI. Check the section '9.1 Client Behavior' in the RFC they talk about
http://www.ietf.org/rfc/rfc3261.txt
I copy here
A CANCEL request SHOULD NOT be sent to cancel a request other than INVITE. Since requests other than INVITE are responded to immediately, sending a CANCEL for a non-INVITE request would always create a race condition.
The following procedures are used to construct a CANCEL request. 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.
If you check the sentence in bold you will see that the Request-URI should be identical with that of the INVITE (along with the other headers the RFC mentions)
So you probably need to get back to your provider and tell them to fix that according to the rfc they pointed at :)
Regards
07-10-2014 10:07 AM
Hello!
Sorry for the delay! and thank you very much for your help!
The ISP insisted that the CANCEL message is based on the CONTACT header and pointed me to this part of the rfc:
8.1.1.8 Contact
The Contact header field provides a SIP or SIPS URI that can be used
to contact that specific instance of the UA for subsequent requests.
The Contact header field MUST be present and contain exactly one SIP
or SIPS URI in any request that can result in the establishment of a
dialog. For the methods defined in this specification, that includes
only the INVITE request. For these requests, the scope of the
Contact is global. That is, the Contact header field value contains
the URI at which the UA would like to receive requests, and this URI
MUST be valid even if used in subsequent requests outside of any
dialogs.
If the Request-URI or top Route header field value contains a SIPS
URI, the Contact header field MUST contain a SIPS URI as well.
But after long discussion they decided to provide E1 instead of sip trunk.
Thank you
-Denis
07-07-2014 05:23 AM
Hi Denis,
Can you ask your ISP to point out where in SIP RFC they fell "cancel" message is generated by using "contact" header ? "Contact" header is used when the dialog is established not before.
By the way can you please collect "debug ccsip all" for this call. Note:- It generates too much logs.
Thanks
Manish
07-05-2014 02:32 AM
Hi Denis,
I suggest you also enable the debug ccsip info and debug ccsip error along with the debug ccsip message, and then do the call again. That should give you more logs on what exactly is happening with the sip layer, and why the router is rejecting the cancel with 481.
Thanks
Sreekanth
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: