SonicWall_Vonage Inbound ok but no outbound.

[mfretwell]

Current system:
SonicWall 2040
Vonage w Softphone option.
Aastra 55i
Have succesfully registered line and extensions and can recieve inbound calls no problem. Install appears to be stable, however, cannot make outbound calls. I have reviewed FAQs and Forums but no of the suggestions appear to be working with this setup.
Here's an example of log:

07:16:52.091 Call::Terminate [CM503008]: Call(16): Call is terminated
07:16:52.076 Call::RouteFailed [CM503014]: Call(16): Attempt to reach "14039985713"[sip:[email protected]:5061] failed. Reason: Not Found
07:16:52.076 CallCtrl:nSelectRouteReq [CM503013]: Call(16): No known route to target: "14039985713"[sip:[email protected]:5061]
07:16:52.045 CallCtrl:nSelectRouteReq [CM503010]: Making route(s) to "14039985713"[sip:[email protected]:5061]
07:16:52.045 Extension:rintEndpointInfo [CM505001]: Ext.101: Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [Aastra 55i/2.0.1.2000 Brcm-Callctrl/v1.7.2.2 MxSF/v3.6.2.5] Transport: [sip:192.168.0.105:5061]
07:16:52.029 CallCtrl:nIncomingCall [CM503001]: Call(16): Incoming call from Ext.101 to "14039985713"[sip:[email protected]:5061]

Any suggestions?

 

[archie]

Check your outbound rules. It seems none has been applied.

 

[mfretwell]

I had setup the following outbound rules:

If Number starts with 0 then strip 1 character and send via Vonage
If Number is either 3, 7, or 10 digits long then send via Vonage

If these rules are not being applied I'm not sure why.

 

[archie]

No wonder, you've dialed 11 digits starting from 1 - it doesn't match any of your rules.
Also I don;t see the reason to route 3 digits long numbers to vonage - it is supposed to be internal numbers.

 

[mfretwell]

So sorry, I'm being a little less than clear...

I setup the 3 digit rule to accomodate general information and emergency numbers 311, 411, 911 etc. Since your comments I have changed the rule to 4 digits which strips a leading 0 to accomodate the need for 3 digit internal lines, I'll just have to tell everyone to dail 0911 in an emergency. Unless there is a better way to do this? I'm thinking of using either 2 or 4 digit internal numbers, rather than 3.

You are correct I do not have an 11 digit rule setup. I have edited the 10 digit rule to prepend a 1, and added an 11 digit rule.
I have also tried 7 digit numbers, such as my cell phone.

When I try to dial out the phone has a dial tone but returns a busy signal for any outside call using any of these rules.

I see that this morning the Server status is reporting a stunserver timeout error which it was not reporting yesterday. I suspect a firewall issue for this problem. Would it be best to have our network DCHP services running on the firewall as opposed to our Windows Server?

 

[mfretwell]

Eureka part 1...
Once we set a One-to-One NAT to a static address on the firewall the lines registered and the firewall tests passed, without any further proxy timeout errors. However, we still can't make an outbound call... Do we need outbound rules defined for every possible number pattern or can we simply use an outbound rule for any call originating at one of the extensions to test?

 

[archie]

Yes, you can have a rule bound to extension without any restrictions on number. But keep in mind that when PBX routes call it first looks for matches to extension numbers. So if you have defined Ext.911 and dial 911 - your call will be routed to that extension, no matter what outbound rules you have.

 

[Andy Schmidt]

Hi,

you really only need a few rules.

Here's what I use. It routes 011 (intl), 3 digit through the local phone company.
For 7 digit calls it prepends 1+our area code, for 10 digit calls it prepends a 1 - then then sends it to our VOIP provider.
11 digit calls are passed straight to the VOIP provider.

If our primary VOIP is no available, we route through a "pay-as-you-go" provider and if we have network problems and neither VOIP provider works, it routes calls through the local phone company.

If we have any technical or quality problems with a particular call, then we can dial a "0" first, which routes the call through the local phone company.

 

[mfretwell]

Ah...the fog is beginning to lift.
We have set some outbound rules and they appear to be being applied however we still cannot dial out.
We get a dail tone at the extension then a busy signal and the message "call failed" at the handset.

Here's a copy of the server log:

07:10:19.683 Call::Terminate [CM503008]: Call(14): Call is terminated
07:10:19.620 Call::RouteFailed [CM503014]: Call(14): Attempt to reach "9985713"[sip:[email protected]:5061] failed. Reason: Not Found
07:10:19.620 CallLeg:nFailure [CM503003]: Call(14): Call to sip:[email protected]:5061 has failed; Cause: 404 Not Found; from IP:216.115.20.41:5061
07:10:19.058 CallCtrl:nSelectRouteReq [CM503004]: Call(14): Calling: VoIPline:10000@[Dev:sip:[email protected]:5061]
07:10:18.917 CallCtrl:nSelectRouteReq [CM503010]: Making route(s) to "9985713"[sip:[email protected]:5061]
07:10:18.917 Extension:rintEndpointInfo [CM505001]: Ext.100: Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [Aastra 55i/2.0.1.2000 Brcm-Callctrl/v1.7.2.2 MxSF/v3.6.2.5] Transport: [sip:192.168.0.105:5061]
07:10:18.902 CallCtrl:nIncomingCall [CM503001]: Call(14): Incoming call from Ext.100 to "9985713"[sip:[email protected]:5061]

As you can see an outbound rule prepends "1403" before calling the Vonage softphone account, but fails and returns a "404 Not Found" error.

The funny thing is that the same call completes using Vonages soft phone appliance, X-Pro. The Firewall tests all work fine. Could this be an outbound proxy problem?

 

[mickp]

This looks exactly like what we experienced last week when attempting to configure a voip provider for Australian ITSP Internode(nodephone). The solution ended up being to remove the entries for "Outbound Proxy Hostname or IP"and "Outbound Proxy Port" for the provider. I'm not sure exactly why this was required but the provider hasn't skipped a beat since.

Hopefully this will also work for you.

Mick.

 

[mfretwell]

Thanks Mick!
Your tip worked like a charm.
Have a cold one on me :mrgreen:
Mike