03-26-2022 06:01 AM
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.
Solved! Go to Solution.
03-28-2022 02:22 AM
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
03-26-2022 06:35 AM - edited 03-26-2022 02:13 PM
03-26-2022 01:23 PM - edited 03-26-2022 01:24 PM
I hope so, will take a look
03-27-2022 12:49 AM
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.
03-26-2022 02:22 PM
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
03-27-2022 05:35 AM
Unfortunately, NAT is not involved in my setup. So the suggestions doesn't really apply. Also no firewall between PSTN SBC and CUBE.
03-27-2022 08:31 AM
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?
03-27-2022 12:52 PM
03-27-2022 11:38 PM - edited 03-27-2022 11:39 PM
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?
03-28-2022 01:54 AM
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"
03-28-2022 02:22 AM
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
03-28-2022 04:45 AM
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.
03-28-2022 08:10 AM
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.
03-28-2022 08:06 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide