ISP SIP Trunk Issues

[Joseph E Spoon]

Hello, we are installing a new SIP trunk from our ISP to replace our PRI.  With the setup the way we have it we are getting ring no answer on inbound calls and fast busy on outbound calls.  The ISP has a Cisco 2900 router that is NATing over to our Cisco 2851 with advipservices firmware.  Behind our Cisco 2851 we have CUCM 8.0.  What could be causing our issues?  Attached is the configuration in the voice gateway.  The ISP Router has the public IP and is NATing the traffic across to 130.0.100.1.  Then there is an outbound dial-peer going to the call manager.  The phone will ring, but the calling party just hears endless ringing even if the called party picks up the phone.  I've only been testing one number since we don't have all of the numbers ported over, i have it translated with a num-exp value.  Also, it works with a phone plugged directly into an FXS port.

[brmeade]

Grab "debug ccsip messages" for an inbound and outbound call and attach.

[Joseph E Spoon]

Thanks for your reply.  Attached are links to two files, one is a debug ccsip all and the other is a debug ccsip messages.

For outbound calls, I'm not able to run a debug since it is a live environment.  I will try and schedule some outbound calls tomorrow to grab those debugs.

Thanks again for your help.

[piyujain]

Joseph,

I checked your configuration attached above.. can you try to remove the below commnads under SIP section and try to make a test call??

header-passing

early-offer forced

sip-profiles 1

If it still fails, can u please share the debugs

debug voice dialpeer inout

debug ccsip all

[Joseph E Spoon]

I removed the options you suggested and I am still having the same issue with inbound calls.  Attached is the log file for an inbound call.

[fb_webuser]

This looks like an ip routing / networking issue where the CUBE can reach the CUCM but the CUCM's return traffic is not reaching the CUBE (this is why the CUBE keeps sending the invites to the CUCM even when the phone is answered, the CUCM's 200 OK is not received by the CUBE). Also explains why outbound calls from CUCM fail with a fast busy.

---

Posted by WebUser Asad Raza from Cisco Support Community App

[Joseph E Spoon]

The call manager and cube are in the same subnet.  CUBE = 130.0.100.1, CUCM = 130.0.100.146 so I'm not sure how there could be a routing or networking issue between the two devices.  Could this have anything to do with the SIP Trunk between the CUBE and CUCM not being setup properly?

[fb_webuser · Accepted solution]

I also see the calls failing with a cause value of 21 which means that the Toll Fraud feature is blocking these calls. Here's how you configure/disable Toll Fraud on CUBE,

http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a0080b3e123.shtml

---

Posted by WebUser Asad Raza from Cisco Support Community App

[Joseph E Spoon]

I will read the documentation on this and try it out.  Thanks for your reply.

[Joseph E Spoon]

I read the documentation and setup the trusted IP list under voice services voip and it is now up and working at least on inbound calls.  I have yet to have a chance to test outbound calls but I will do that this afternoon and let you guys know if it works.  Current config is attached for future reference.  Thanks again for all of the help.

[Joseph E Spoon]

I'm still having issues with Outbound calls.  I've set this up in a CME enviroment so as not to interfere with there normal call processing.  Attached is a log of what I'm seeing with outbound calls.  Any advice is appreciated.

Thanks

[brmeade]

Did you have debug ccsip messages turned on for that call?  I don't see any SIP messaging.

[Joseph E Spoon]

Sorry I did not have ccsip messages debugging on that one.  Attached is a new debug with that enabled.

Thanks for your response.

[brmeade]

Joseph,

This shows your SIP Trunk is trying to register and the provider is sending back a "405 Method Not Allowed".  Are you sure your carrier needs you to register your SIP Trunk?

Brian

[Joseph E Spoon]

You are correct, I don't believe they do require registration, I'm removing those options and retrying a test call.  I will post the results momentarily.