Dismiss Notice
We would like to remind you that we’re updating our login process for all 3CX forums whereby you will be able to login with the same credentials you use for the Partner or Customer Portal. Click here to read more.

SonicWall_Vonage Inbound ok but no outbound.

Discussion in '3CX Phone System - General' started by mfretwell, May 27, 2008.

Thread Status:
Not open for further replies.
  1. mfretwell

    Joined:
    May 26, 2008
    Messages:
    25
    Likes Received:
    0
    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:14039985713@192.168.0.105:5061] failed. Reason: Not Found
    07:16:52.076 CallCtrl::eek:nSelectRouteReq [CM503013]: Call(16): No known route to target: "14039985713"[sip:14039985713@192.168.0.105:5061]
    07:16:52.045 CallCtrl::eek:nSelectRouteReq [CM503010]: Making route(s) to "14039985713"[sip:14039985713@192.168.0.105:5061]
    07:16:52.045 Extension::printEndpointInfo [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::eek:nIncomingCall [CM503001]: Call(16): Incoming call from Ext.101 to "14039985713"[sip:14039985713@192.168.0.105:5061]

    Any suggestions?
     
  2. archie

    archie Well-Known Member
    3CX Support

    Joined:
    Aug 18, 2006
    Messages:
    1,299
    Likes Received:
    0
    Check your outbound rules. It seems none has been applied.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  3. mfretwell

    Joined:
    May 26, 2008
    Messages:
    25
    Likes Received:
    0
    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.
     
  4. archie

    archie Well-Known Member
    3CX Support

    Joined:
    Aug 18, 2006
    Messages:
    1,299
    Likes Received:
    0
    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.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  5. mfretwell

    Joined:
    May 26, 2008
    Messages:
    25
    Likes Received:
    0
    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?
     
  6. mfretwell

    Joined:
    May 26, 2008
    Messages:
    25
    Likes Received:
    0
    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?
     
  7. archie

    archie Well-Known Member
    3CX Support

    Joined:
    Aug 18, 2006
    Messages:
    1,299
    Likes Received:
    0
    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.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  8. Andy Schmidt

    Andy Schmidt New Member

    Joined:
    Apr 3, 2008
    Messages:
    118
    Likes Received:
    0
    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.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  9. mfretwell

    Joined:
    May 26, 2008
    Messages:
    25
    Likes Received:
    0
    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:9985713@192.168.0.105:5061] failed. Reason: Not Found
    07:10:19.620 CallLeg::eek:nFailure [CM503003]: Call(14): Call to sip:14039985713@sphone.vopr.vonage.net:5061 has failed; Cause: 404 Not Found; from IP:216.115.20.41:5061
    07:10:19.058 CallCtrl::eek:nSelectRouteReq [CM503004]: Call(14): Calling: VoIPline:10000@[Dev:sip:14036687437@sphone.vopr.vonage.net:5061]
    07:10:18.917 CallCtrl::eek:nSelectRouteReq [CM503010]: Making route(s) to "9985713"[sip:9985713@192.168.0.105:5061]
    07:10:18.917 Extension::printEndpointInfo [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::eek:nIncomingCall [CM503001]: Call(14): Incoming call from Ext.100 to "9985713"[sip:9985713@192.168.0.105: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?
     
  10. mickp

    Joined:
    Jun 9, 2008
    Messages:
    72
    Likes Received:
    0
    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.
     
  11. mfretwell

    Joined:
    May 26, 2008
    Messages:
    25
    Likes Received:
    0
    Thanks Mick!
    Your tip worked like a charm.
    Have a cold one on me :mrgreen:
    Mike
     
Thread Status:
Not open for further replies.