CUBE on CSR1000V, inbound call fail with 'Invalid Host'

[Flemming Ortvald]

After enabling "vrf" on the interfaces inbound calls from PSTN fails, outbound calls work OK.

The CUBE sends this in response to invites:

Sent:
SIP/2.0 400 Bad Request - 'Invalid Host'
Via: SIP/2.0/UDP 128.77.191.7:5060;branch=z9hG4bKgqa03a10d8e8ktoa2010.1
From: <sip:+4544358346@vk151772.hvoip.dk;user=phone>;tag=456550537-1648291623241-
To: "4538140215 4538140215"<sip:+4538140215@vk156413.hvoip.dk>;cscf;tag=303D2B4-1E58
Date: Sat, 26 Mar 2022 10:47:03 GMT
Call-ID: BW114703241260322514219616@188.181.141.4
CSeq: 585832613 INVITE
Allow-Events: telephone-event
Reason: Q.850;cause=100
Server: Cisco-SIPGateway/IOS-17.3.4a
Session-ID: e2c8c88daac159a4a2f5b4bb0a06956f;remote=c3b1246b94585d26b746a2cd6209b459
Content-Length: 0

I have disabled ip address security:

voice service voip
no ip address trusted authenticate

But that did not solve the problem.

Looking for good ideas for troubleshooting.

[Roger Kallberg]

Maybe this or this could help. 

[Flemming Ortvald]

I hope so, will take a look

[Roger Kallberg]

Please note I updated my response and added a second link to it. In that post the solution was to do a translation of the information in the invite to something that is known by the router. Try it out to see if that works for you.

[Flemming Ortvald]

Not quite, I wonder if the fact that the invite does not contain the IP-address of the cube, but a domain-name is to blame.

I tried adding an "ip host" entry, but this didn't change the behavoir.

All suggestions welcome.

New config attached.

And debug of failed call. Call from +4544358346 to +4538140212

[Flemming Ortvald]

Unfortunately, NAT is not involved in my setup. So the suggestions doesn't really apply. Also no firewall between PSTN SBC and CUBE.

[Roger Kallberg]

I’ve never configured a voice gateway with VRF, so somewhat out on the deep end with this. However based on this document your server group configuration does not seem to follow the restrictions for how to use this with VRF on a voice gateway.

Can you share the output of these debugs running in parallel?

• deb ccsip message 
• deb ccsip verbose 
• deb voip ccapi inout 

[Flemming Ortvald]

Here it comes, call from +4544358346 to +4538140212

[b.winter]

Hi,

Who are those IP addresses: 128.77.191.7 (provider?) and 188.181.141.4 (if you have no NAT, where does this IP come from?

In my opinion, just quickly screening your config the problem is that your router isn't listening to the hostname and/or IP (vk156413.hvoip.dk? and/or 188.181.141.4?) where the provider is sending the INVITE to.

Have you tried to manipulate the SIP headers with an incoming SIP profile, so like the headers "TO" or the request header contain the CUBE's IP instead of the hostname?

[Flemming Ortvald]

This setup worked, until I applied VRF to the interfaces, 128.77.191.7 is indeed the provider IP, while 188.181.141.4 is the ip of the caller (beyond the provider).

I have tried mapping "vk156413.hvoip.dk" to my local IP towards provider"ip host vrf SOStestG34 vk156413.hvoip.dk 93.167.254.4"

[b.winter · Accepted solution]

This even more confirms my opinion, that your routing doesn't feel responsible to the SIP messages.

Why do you think, using a command for DNS resolution, will help with your SIP problem? That has nothing to do with manipulating SIP headers.

To achieve this, you need to use SIP profiles.

You need to manipulate the SIP INVITE coming from the provider, so that the Request-URI and TO headers contain the IP of your CUBE instead of the FQDN (vk156413.hvoip.dk).

Something like:

voice class sip-profiles xxx
 rule 1 request INVITE sip-header SIP-Req-URI modify "@vk156413.hvoip.dk" "@<IP>"
 rule 2 request INVITE sip-header To modify "@vk156413.hvoip.dk" "@<IP>"
!
dial-peer voice xxx voip
 voice-class sip profiles xxx inbound 

[Roger Kallberg]

This is exactly what I also related to in my first response which referenced a few other community posts. The second one to me perfectly seems to match what you suggest in your response.

[Flemming Ortvald]

Hi Roger

Thank you for your valuable suggestions.

Still seems a little like "black magic", why I need this on one system, and not on another.

[Flemming Ortvald]

This did the trick.

The reason I haven't gone down this path earlier, is that my production setup (this is a test system) also has VRF assigned to the PSTN side dial-peers, though not to the CUCM side ones, which is how I configured the test CUBE.

And that it worked without modifying before applying VRF's

Thank you for the suggestions and patience