cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3561
Views
0
Helpful
34
Replies

CUCME do not register, no outbound call

o0chrisb0o
Level 1
Level 1

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.

34 Replies 34

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

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

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?

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

 

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.

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."

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!

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?

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!

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