CUCME do not register, no outbound call

[o0chrisb0o]

Hi,

I'm pulling my air out since last week. Here's my problem. It has been over a year that I setup a phone system, and everything was working fine. Then I changed my setup last week.

My old setup was basically like this:

cucme (2811) ==> ISP Router ==> Twilio (SIP Trunk) (NAT was made directly on the 2811)

Now my setup is as follow

cucme (2811) ==> router (1941) ==> PFSense FW (NAT happen here) ==> ISP Router (Bridge Mode) ==> Twilio.

What's working:

• All phones can communicate between them internaly
• All inbound call works flawlessly

What's not working:

• Outbound calls

Here's the symptoms when I try to do an outbound call, when a pickup the phone and dial a outside number, I press 9, then I hear the fast dialtone, as usual, then type the number, I see the "Ring Out" on the phone screen, but nothing happen, no sound or click can be heard on the phone.

When I check the debug messages, I can see that the systems try to register to Twilio, but I do not receive any response from them. When I check the debug console at Twilio, it seems that they do not even received anything. (I'll include all the logs, pcap (from firewall) and config)

I have a feeling that it's related to the NAT, since it was working perfectly when the NAT was made by the 2811, I check for STUN and ALG but I don't know where to start or how it really works.

I would like to get your opinion on the matter, right now it beyond me and I would like to learn from that experience!

Looking forward for your help, I'm sure it's a small detail that I overlooked.

[TONY SMITH]

So you need to have that interface bound under voice service for it to be used for the registration traffic.   That sets the binding globally, so if you have other SIP dial peers where it's not appropriate you need to over ride that at the dial peer level.

At least setting this in voice service you should be sending your Register sourced on the correct address ..

voice service voip
 sip
  bind control source-interface FastEthernet0/2/0
  bind media source-interface FastEthernet0/2/0

[o0chrisb0o]

Thanks, I tried but it did not work, incoming calls wasn't working anymore :(

[monster.speaks]

A few questions:

1. Did you remove the sip bind commands from the router?

2. Is your firewall still doing NATting?

You might want to check the logs on Twilio portal as they have this option. This will help you view the logs as seen from Twilio.

Can you also share the log of the most recent call that has failed?

[o0chrisb0o]

Hi!

1. Did you remove the sip bind commands from the router?

No, in fact I just put it there.

2. Is your firewall still doing NATting?

Yes, my firewall still NATing.

Strangely enough, on Twilio, in the logs I see nothing related to this problem, I'll see other type of error, like if my public IP change, and I did not change it on Twilio and try a call, it will give me a 403 Forbidden error, but nothing else, like if it's working properly. Have a look at my last attempt to make a call in the attached file.

Thanks

[monster.speaks]

So, on Twilio you do not see this call, but if you change the public IP you do see the call with the expected error.
From the logs (if they are complete), the call is reaching Twilio which prompts for username and password and ideally the credentials need to be sent on a re-invite, which seems to be going as well based on the following INVITES. You might want to take a capture on the device that sits on the edge as well to look at the communication. It stops working when the re-invites are initiated.

[o0chrisb0o]

Hi! thanks again for your help.

So I captured  packets on my WAN interface on my firewall. There's two thing that jump out:

1. I got a 407 packet which is strange, I did investigated in to it but I did not find why it does not authenticate correctly, even after adding a new username and password.
2. When I compare with an incoming call, in the SDP message, the "Connection Information (c): IN IP4 192.168.20.1" on the incoming call is the public IP from Twilio, while the outgoing call show my CUCME private address. My guts tell me that there's something there...

Attached you find my captured. Let me know what you think, I feel we are on the right track. I did try to modify the header with sip-profiles but with no success, perhaps it will work better with stun-profiles.

EDIT: I just read on Twilio website that the 407 is normal:

"If you are using User Credentials, your SIP INVITE will be challenged with a 407 Proxy Authentication Required requesting the appropriate user credentials.

By the end of this step your trunk will be able to process termination calls from your communications infrastructure, via Twilio, to the PSTN."

[o0chrisb0o · Accepted solution]

Hey Guys,

I wasn't able to work on this matter for a while, but yesterday I've been able to make some significant progress. I find out, by comparing an old working backup configuration with my actual setup that a small diffrence that I overlook and that Twilio picked up this time.

In the translation rules, before, it was configured like this:

rule 1 /1001/ /5345551212/

But before, in my old config it was like this:

rule 1 /1001/ /+15345551212/

But the most significant change that made the whole thing " work " is adding the following, a voice class:

voice class sip-profiles 1
 request INVITE sip-header Contact modify "<sip:user@192.168.20.1:5060>" "<sip:user@my_public_ip:5060>

then call it in the dial-peer:

dial-peer voice 9 voip
 --- snip ---
 voice-class sip profiles 1
 -- snip --
 no vad

I put the word work in quote, although it worked, it takes a good 15-20 seconds before the call is connected and start to ring! You guys have any idea what could cause such a delay? And incoming calls cut after 12 seconds.

Thanks!

[TONY SMITH]

Post up debugs for both scenarios (1) The outbound call with delay before final connection and (2) inbound call dropping after 12 seconds.   We need to know which end is waiting for what.   Do you get normal two-way audio in both cases?

[o0chrisb0o · Accepted solution]

Hi Tony,

The outgoing call delay is now fixed, I recently changed my DNS servers address and did not change the setting in my configuration, once changed to my new DNS server address, it connected without delay. The delay was caused by the time it took to do the lookup then fall back on 1.1.1.1, my secondary name server.

For the incoming calls the problem still there, I'll post the output of the logs a little bit later today.

Edit: I do get two-way audio in both case. Added Log Files

Thanks!

[TONY SMITH]

For the incoming call, the call is ended from your end.  It looks to me as if it's waiting for an ACK from the service provider.  See the multiple OKs that you're sending with no response.

Could you confirm what the devices are, 192.168.20.1,  192.168.20.4 and 172.18.11.232

[o0chrisb0o]

Hi thanks for your precious help,

192.168.20.1 it's my router 2811 with phone services

192.168.20.4 is my CUE (auto-attendant)

54.172.60.3 Twilio Infra.

172.18.11.232, it's my IP (that I changed in the logs, for privacy reason)

All outgoing call works perfectly!

[TONY SMITH]

Can we see debugs for a working outbound call?

[o0chrisb0o]

Of course!

Right off the bat, one the difference between incoming and outgoing calls is that it manages all the way through by the CME (192.168.20.1) there's no trace of the CUE (192.168.20.4). Here's a breakdown of the info:

My Public IP (tokenerized): 184.144.197.120

Called Phone Number : 5346661212
CUE Phone Number : 5345551212

These IPs seems to be part of Twilio network : 172.18.11.114, 34.203.250.208,

Trunk Twilio: 54.172.60.0

[TONY SMITH]

You'll see that with the outbound call, you send an ACK after the call connects (following the OK/SDP from the provider).  So I'd suggest a couple of steps, firstly can you reconfigure for test purposes so a call goes direct to a phone and not to the CUE auto attendant.  Secondly, ask the service provide why they're not sending an ACK in response to your OKs.

[o0chrisb0o]

I changed the setup so goes directly to the phones when an incoming call gets in. I did a test and the same thing happens, the call gets cut after 20 sec flat. When I compare an incoming call and outgoing calls I see the difference, the ACK packet is present while I make an outgoing call. I'll investigate that route as why it does that. The problem seems to lie there. I included the log of the call I did while it doesn't go through the CUE. If you see something, let me know.

Edit: Upon reviewing some troubleshooting tips on the provider website, I found this, which I'll explore:

"

On Origination calls (from PSTN to your PBX): there is two-way audio, but the call drops after 20 or 30 seconds

Cause: Your SIP infrastructure is returning a 200 OK with a Contact header which contains a Private IP Address. As Twilio is required to send the ACK back to the IP Address in the Contact header, the ACK is being sent out to that Private IP Address. Since Private IP Addresses are not publicly routable, the ACK never reaches your SIP Infrastructure, so the call times out on that end and is torn down.

• Your SIP infrastructure should use Publicly Routable IP addresses in the Contact header when responding to an INVITE from Twilio.

"

So now I need to figure out how to modify this. So far I wasn't able with :

request INVITE sip-header Contact modify "<sip:+15345551212@192.168.20.1:5060>" "<sip:+15345551212@76.64.244.127:5060>"