Incoming SIP Calls Failing - My outgoing is fine....

Answered Question
Sep 29th, 2011
User Badges:

We have a UC540 set up in the office, registered with the ITSP for SIP and can make calls quite happily, out over the SIP trunks. When I call in to the SIP number however, all I receive back is busy tone. The call is being delivered to the Public IP address of the network the UC 540 is connected to, but is being rejected by the UC540 with the error:


400 Bad Request - 'Invalid Host'


Where on CCA can I fix this issue please? Any and all help gratefully received.

Correct Answer by David Trad about 5 years 10 months ago

Hi Aaron,


It is probably a simple solution such as adding in your ITSP IP address into the allowed list, when enabling SIP on the system that ACL's start to lock the box down to protect it from Toll fraud a little more agressivley than if you were not using SIP, it also has other peripheral settings such as SOURCE lists and what not.


If you contact the ITSP and ask them for a list of IP addresses that they may use for either fail over, load balancing or for any other reason, you would then log into CCA and go into your SIP Trunk drawer and add them into your trusted list, this should open up the system to all inbound requests and should fix it up.


If the above does not work then there might be a more deep seeded issue that needs to be looked at.



Cheers,


David.

:D

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Thomas Antony Thu, 09/29/2011 - 13:30
User Badges:

Hi Aaron,


I did have this problem a few days ago.

Your UC probably does have a private IP and his behind a Firewall which is doing PAT.


The Cisco CME does not really like PAT.

The UC is analyzing the VIA Header within the incoming SIP packet which is the public IP from your firewall.

If this IP is not configured on the UC (which of course is not) incoming calls will be rejected with "400 Bad Request - 'Invalid Host'"

http://www.cisco.com/en/US/docs/ios/voice/sip/configuration/guide/sip_cg-msg_tmr_rspns.html#wp1056883


As a workaround i created a local loopback interface with the public IP of the firewall.



It would be great if someone could explain this behavior in more detail.

Is this workaround supported or is there a better configuration when UC is behind a Firewall which is doing PAT?

craig.corbett Thu, 09/29/2011 - 14:28
User Badges:

It does depend on many things. You may need to permit a few IP address on the sip provider side to allow them access in, likewise as Thomas suggested it could be a NAT issue.


I’d recommend taking a Sip debug via the CLI –


Issue the following command, capture in a text file while making an inbound call and post here.

debug ccsip all


It is also worthwhile to note that having and Calling Cisco SMB support in this scenario is worth while


Also let us know what provider you are using. Also ask them if you should be trusting additional IP’s.


Cheers,


Craig.

aaronletheren Fri, 09/30/2011 - 02:18
User Badges:

Hi Craig,


THanks for the info. I have attached the debug output to the post. We are using Voiceflex as the ITSP. This kit is NFR, and as such we have no support contract. We have recently purchased a support contract for the kit and I am awaiting confirmation of that being live before I seek support from STAC.


I will need to implement any work around using CCA, and the firewall is currently disabled on the UC540


I look forward to your comments on the attached trace.


Regards,


Aaron

JP Rike Fri, 09/30/2011 - 12:31
User Badges:

Don't put the UC behind a firewall, let the UC be the firewall. I went through this for months with the SA in front of the UC. Got rid of the SA, let the UC do everything and it works really, really well. No issues, since moving away from the SA.


- JP

Correct Answer
David Trad Fri, 09/30/2011 - 17:46
User Badges:
  • Gold, 750 points or more
  • Cisco Designated VIP,

    2013 Small Business

Hi Aaron,


It is probably a simple solution such as adding in your ITSP IP address into the allowed list, when enabling SIP on the system that ACL's start to lock the box down to protect it from Toll fraud a little more agressivley than if you were not using SIP, it also has other peripheral settings such as SOURCE lists and what not.


If you contact the ITSP and ask them for a list of IP addresses that they may use for either fail over, load balancing or for any other reason, you would then log into CCA and go into your SIP Trunk drawer and add them into your trusted list, this should open up the system to all inbound requests and should fix it up.


If the above does not work then there might be a more deep seeded issue that needs to be looked at.



Cheers,


David.

:D

Actions

This Discussion

Related Content