×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

481 Call Leg/Transaction Does Not Exist

Answered Question
Jul 4th, 2014
User Badges:

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

Attachment: 
Correct Answer by cgeorgia4 about 3 years 1 month ago

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (4 ratings)
Loading.
Manish Prasad Sat, 07/05/2014 - 02:01
User Badges:

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:[email protected]: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

denis.moiseenko Mon, 07/07/2014 - 02:27
User Badges:

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

Correct Answer
cgeorgia4 Mon, 07/07/2014 - 03:06
User Badges:

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

denis.moiseenko Thu, 07/10/2014 - 10:07
User Badges:

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

Manish Prasad Mon, 07/07/2014 - 05:23
User Badges:

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

Sreekanth Narayanan Sat, 07/05/2014 - 02:32
User Badges:
  • Cisco Employee,

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

Actions

This Discussion