Inbound SIP calls fail - 400 Bad Request - 'Invalid Host'

Derrick Filippelli · ‎10-13-2015

I seem to be having an issue with inbound calls from my SIP ITSP (voip.ms). Calls are reaching my voice gateway (CME Version 8.6) are failing with an error SIP/2.0 400 Bad Request - 'Invalid Host'.

I am getting the SIP Invite message but respond with SIP/2.0 400 Bad Request - 'Invalid Host'. From what I can see from researching this issue it is likely caused by a natting issue.

I am also seeing the following right before the 400 error:

000265: Oct 13 23:05:19.948: //-1/xxxxxxxxxxxx/SIP/Error/sipSPI_validate_own_ip_addr: ReqLine IP addr does not match with host IP addr

000266: Oct 13 23:05:19.948: //-1/B5A63090801E/SIP/Error/sact_idle_new_message_invite: Invalid URL in incoming INVITE

I have tried both with and without SIP ALG enabled on my firewall. Both seem to fail.

Anyone have any ideas?

Dennis Mink · ‎10-13-2015

Derrick,

As you already indicated, the key is:

000266: Oct 13 23:05:19.948: //-1/B5A63090801E/SIP/Error/sact_idle_new_message_invite: Invalid URL in incoming INVITE

Can you add the debug ccsip of a failing call and the config of your CME to this case, so we can have a look at what the INVITE actually contains.

cheers

Please remember to rate useful posts, by clicking on the stars below.

Derrick Filippelli · ‎10-13-2015

Thanks. Please see attached.

Ayodeji Okanlawon · ‎10-13-2015

Derrick,

INVITE sip:2894725526@192.249.102.12

Before a router processes a request such as an INVITE, the first thing it does is to check if the request is meant for it and that's done by looking at the host address in the RURI. In this case, the host address (192.249.102.12), doesn't match any interface configured on the router. This may be a Nat issue.

Please rate all useful posts

Derrick Filippelli · ‎10-14-2015

Thanks for the response. That public IP is natted on the firewall to the LAN IP on the voice router.

If I enable SIP ALG on my firewall the invite uses the LAN IP of the voice router but the call still doesn't go through.

The strange thing is I have the exact same setup working at another location with almost the same configuration. The invite uses the public ip with SIP ALG off on the firewall.

Any ideas?

Vivek Batra · ‎10-14-2015

Dirrick,

You definitely need to check how you can correct the request-uri part of INVITE however I suggest to look at dial-peer configuration too.

You've 'incoming called-number .' command in two dial-peers viz dial-peer voice 206 voip and dial-peer voice 500 voip. So either of the one will be matching inbound call from ITSP.

If dial-peer 206 is being matched, you also have translation-profile attached here which is translating number to 250 and now you don't have outbound dial-peer matching with 250. Call has to fail.

If dial-peer 500 is being matched, this will further match dial-peer 207 as outbound dial-peer however you again have the same called party number as destination-pattern under this dial-peer (/207) viz 2894725526, so where do you want to take this call? Again there is no session target command here, so call has to fail.

- Vivek

Derrick Filippelli · ‎10-20-2015

Thanks for your reply.

I want the call to come in via dial-peer 206 and get translated to 250, 250 is the hunt pilot number. I assumed that the router knows how to get to 250 since it is on the same device and not on a CUCM Server. How would the session target command be configured if I want the call to stay within the CME router.

How would you suggest to configure the inbound dial-peer?

Vivek Batra · ‎10-20-2015

Ok, if 250 is hunt pilot then you don't need to configure what I suggested before.

For verification, I suggest to add new dial-peer for inbound call (from ITSP) as follows;

dial-peer voice 2894 voip

incoming called-number ^2894725526$

translation-profile incoming INCOMING-SIP

session protocol sipv2

voice-class codec 1

voice-class sip bind control source-interface Port-channel1.10

voice-class sip bind media source-interface Port-channel1.10

dtmf-relay rtp-nte

no vad

Make a test call. Use debug voice ccapi inout and ensure incoming call from ITSP hits the above dial-peer and observe the results. Then share the output of debug ccapiinout and debug ccsip messages.

- Vivek

Derrick Filippelli · ‎11-28-2015

I am still having issues with this. I fixed up my inbound dial-peer and confirmed that inbound calls are now hitting the following dial-peer.

The translation profile INCOMING-SIP will translate calls to a hunt pilot number.

dial-peer voice 207 voip
description INCOMING DIDs
translation-profile incoming INCOMING-SIP
session protocol sipv2
session target dns:toronto4.voip.ms
session transport udp
incoming called-number .%
dtmf-relay cisco-rtp rtp-nte
codec g711ulaw

As of now I am getting 2 different scenarios. See the attached SIP message diagrams. From the research I have done regarding these 2 messages it seems to be releated to a NAT issue. Although I have tried with both SIP ALG enabled and disabled on my firewall and still no luck.

SIP/2.0 400 Bad Request - 'Invalid Host'

OR

SIP/2.0 500 Internal Server Error

Any ideas?

Ayodeji Okanlawon · ‎10-14-2015

We need to know why the call fails when the correct IP address is used. Please send a debeug ccsip message

Please rate all useful posts