Solved: Forwarding rules MAJOR bug V9

Discussion in '3CX Phone System - General' started by acolville, Aug 20, 2010.

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

    Joined:
    Jul 27, 2009
    Messages:
    80
    Likes Received:
    0
    OK, I may be one of the few people with multiple sites, but surely not the only one! The new forwarding rules look, on the surface, great, but in my set up they just do not work! They worked fine in V8, and if my set-up needs changing for them to work in V9 then that's no problem.

    Here's the problem.

    Site 1 ext's 100-199
    Site 2 ext's 200-299
    Site 3 ext's 300-399

    Ext 200 has a forward all calls to 100 - User is at the other site

    201 dials 200 and it correctly forwards the call over the bridge to 100

    101 dials 200 and now the call fails - logs on site 2 show "There's no outbound rule for external number '100' defined"

    301 dials 200 and it correctly forwards the call over the bridge to 100

    This all worked fine in V8.

    So a bit more digging...

    What is the difference between site 1 and 3 it works for 3 but not one? The difference is how the bridges are setup:

    Site1 (Slave) -> Site 2 (Master)
    Site3 (Master) <-Site 3 (Slave)

    So it works only when the site calling is slave.

    I will experiment with mutiple bridges,but this seems like a bug to me.
     
  2. Eurylink

    Eurylink New Member

    Joined:
    May 25, 2008
    Messages:
    174
    Likes Received:
    3
    Re: Forwarding rules MAJOR bug V9

    Hi,
    i have 3 bridge configured like you with version 9 but they are set with "tunnel". I Tested now for your issue but I have no problem. Maybe you can solve the issue only setting connection with tunnel.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  3. acolville

    Joined:
    Jul 27, 2009
    Messages:
    80
    Likes Received:
    0
    Re: Forwarding rules MAJOR bug V9

    Thanks, I will try this.

    We use Draytek routers which are able to make L2TP VPN links, so we should not need to use a tunnel, but if it works and the performance is OK then fine!
     
  4. MichaelB

    MichaelB Member
    3CX Support

    Joined:
    Aug 25, 2009
    Messages:
    407
    Likes Received:
    8
    Re: Forwarding rules MAJOR bug V9

    Hi, what is the status of this post?
    Thanks and Regards
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  5. acolville

    Joined:
    Jul 27, 2009
    Messages:
    80
    Likes Received:
    0
    Re: Forwarding rules MAJOR bug V9

    After some fairly intense testing I have found that if the PBX is on a VLAN, with the router on a different VLAN, then remote sites are blacklisted, see the following...

    Here a call is being placed by 100@192.168.6.2 across a DIRECT bridge to 200@192.168.8.2

    This breaks the multi-site capabilites of 3CX, so until resolved we have to stay with V9.
    Please help!


    11:48:40.518 [CM506001]: STUN request to resolve SIP external IP:port mapping is sent to STUN server 96.9.132.83:3478 over Transport 192.168.8.2:5060
    11:45:43.892 Requests rate from IP 192.168.6.2 is too high! Blacklisted for 167 seconds
    11:45:43.892 [CM500002]: Unidentified incoming call. Review INVITE and adjust source identification:
    INVITE sip:200@192.168.8.2:5060 SIP/2.0
    Via: SIP/2.0/UDP 192.168.6.2:5060;branch=z9hG4bK-d8754z-bb7df9178011c064-1---d8754z-;rport=5060
    Max-Forwards: 70
    Contact: <sip:192.168.6.2:5060>
    To: <sip:200@192.168.8.2:5060>
    From: "10002"<sip:192.168.8.2:5060>;tag=a448d841
    Call-ID: ZDdmY2NmNWVhYjcyM2Y2MDgzMzIyMGE1MjM1NDc3Mzc.
    CSeq: 1 INVITE
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE
    Supported: replaces
    User-Agent: 3CXPhoneSystem 9.0.13677.0
    Content-Length: 0
    Remote-Party-ID: "10002"<sip:10002@192.168.8.2:5060>;party=calling
     
  6. LeonidasG

    LeonidasG Support Team
    Staff Member 3CX Support

    Joined:
    Nov 19, 2008
    Messages:
    1,500
    Likes Received:
    98
    Re: Forwarding rules MAJOR bug V9

    Hi,

    It would help if you sent a Wireshark capture / Clear logs with only a call to that remote site to my mail on lg@3cx.com

    Also, are you making multiple calls to this remote site at the same time when this occurs? Or only 1 call?
    I'd suggest you go to: Settings > Advanced > Anti-Hacking and increase All 3 Security barriers to 9999, restart the phonesystem and try reproducing the issue.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  7. acolville

    Joined:
    Jul 27, 2009
    Messages:
    80
    Likes Received:
    0
    Re: Forwarding rules MAJOR bug V9

    I have sent a more detailed description of what I think is happening, but for those reading this series of posts please note:

    When testing bridges they appear to work in broadcast mode and not direct. So if you setup a parallel server to test (ie when a big new release comes along) and it is on the same subnet (but different IP) they will conflict.

    There is still another BIG issue with the new forwarding rules:

    Call dialled direct to an "external" number (it is picked up by an outbound rule and sent down a bridge)


    15:44:14.862 [CM503008]: Call(11): Call is terminated
    15:44:13.974 [CM503007]: Call(11): Device joined: sip:10002@192.168.6.1:5060;rinstance=deffda0693c8db30
    15:44:13.965 [CM503007]: Call(11): Device joined: sip:204@192.168.8.22:3072;line=4eqoft4a
    15:44:11.550 [CM505004]: Bridge:[Kitehill-Beggars] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [3CXPhoneSystem 9.0.13677.0] PBX contact: [sip:10002@192.168.8.1:5060]
    15:44:11.549 [CM503002]: Call(11): Alerting sip:10002@192.168.6.1:5060;rinstance=deffda0693c8db30
    15:44:11.082 [CM503025]: Call(11): Calling PBXline:198@(Ln.10002@Kitehill-Beggars)@[Dev:sip:10002@192.168.6.1:5060;rinstance=deffda0693c8db30]

    Now set forwarding on the extension to forward to an external no ie 198

    15:47:06.052 [CM503020]: Normal call termination. Reason: No outbound rule
    15:47:06.052 [CM503016]: Call(12): Attempt to reach <sip:204@192.168.8.1:5060> failed. Reason: Busy
    15:47:06.052 [CM303006]: There's no outbound rule for external number '198' defined
    15:47:06.030 [CM303006]: There's no outbound rule for external number '198' defined
    15:47:06.006 [CM503010]: Making route(s) to <sip:204@192.168.8.1:5060>
    15:47:06.005 [CM505004]: Bridge:[beggars-Woodside] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [3CXPhoneSystem 9.0.13677.0] PBX contact: [sip:10001@192.168.8.1:5060]
    15:47:05.991 [CM503001]: Call(12): Incoming call from 10001@(Ln.10001@beggars-Woodside) to <sip:204@192.168.8.1:5060>

    It fails with No Outbound Rule, yet there clearly is an outbound rule for numbers beginning 1 of length 3 to use the bridge!

    Is this a bug, or am I missing something in the configuration? In version 8 this worked! ie a forward to an external number would apply the outbound rules and forward correctly down the bridge.
     
  8. nb

    nb Support Team
    Staff Member 3CX Support

    Joined:
    Jun 7, 2007
    Messages:
    2,129
    Likes Received:
    153
    Re: Forwarding rules MAJOR bug V9

    Hi

    bridges and tunnel work the same. The problem is not there

    I still need to understand why this is failing

    FW rule on 200 to take him back to site's 1 extension 100.

    so 101 should dial prexix site 2 + 200, PBX at site 2 should load fw rules and take call back to PREFIX site 1 ext 100.

    IMPORTANT:

    See this log you mentioned?
    You see rerquests rate is too high?
    In v9 we implemented a anti hack. So you have to relax the environment a bit.

    Send me the options you have configured in the anti hack section.

    Configure them like wise (options 1,2,3,4,5 from top to bottom ok)
    Opt 1 25
    opt 2 1800
    opt 3 200
    opt 4 2000
    opt 5 4000

    if they are different there could be the problem.

    ====

    I can offer you a remote session and we will check things out if you want - contact me on nb@3cx.com
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  9. acolville

    Joined:
    Jul 27, 2009
    Messages:
    80
    Likes Received:
    0
    Re: Forwarding rules MAJOR bug V9

    UPDATE:

    Reading through these posts it seems that one issue was clouding another and As I am still having problems I thought it would be good to separate them out.

    1. Bridges broadcast traffic they do not direct it
    What this means is that if you have a bridge listening on a subnet it does not care where the traffic has come from, even though when you define the bridges you enter an ip address. In normal use this does not matter. But be wary if setting,as I did, up a side by side installation with a different IP address in order to test new updates (ie V8-v9) as the bridges will interfere with each other. - I understand this now and know what to look out for.

    2. The forwarding rules do NOT work.
    This may be due to the way our outbound rules are set but the following, which all worked in V8 now all fail with "no outbound Rule Defined"
    a) Forwards to external numbers
    b) Forwards to mobiles
    c) Forwards to extentons over the bridge (this was achieved using a external forward)

    I have sent 3CX all the site backups, but no fix yet.

    I have now heard nothing for a week, so hopefully they are working on a fix - It would be great if they could at least let me know!
     
  10. acolville

    Joined:
    Jul 27, 2009
    Messages:
    80
    Likes Received:
    0
    Re: Forwarding rules MAJOR bug V9

    UPDATE: Resolved

    I have just spent some time with Nicky and Teamviewer and this issue is now resolved - thank you Nicky.

    We had a complex set of outbound rules - which did work under v8, but not with v9. Nicky simplified these and now evrything works!

    Thanks also to Leonidas who I know was also working on this behind the scenes.
     
  11. kolagola

    Joined:
    Sep 30, 2010
    Messages:
    9
    Likes Received:
    0
    hi,

    Could you please give the solution to your problem on this forum.

    Thanks,

    Kola
     
  12. nb

    nb Support Team
    Staff Member 3CX Support

    Joined:
    Jun 7, 2007
    Messages:
    2,129
    Likes Received:
    153
    Outbound rules were conflicting each other. You have to think first match - first is applied.
    When we delved deeper trying different scenarios we found a problem in outbound rule ranges. Next update will have the fix for this.

    What is your problem?
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  13. kolagola

    Joined:
    Sep 30, 2010
    Messages:
    9
    Likes Received:
    0
    Hi,
    Thanks for your reply.....

    my scenario is that I have two extensions 100 & 101

    I am using 3cx softphone as ext 100 on desktop (3cx server is also installed on this machine) & eyebeam as ext 101 on laptop.

    Inbound is set to go directly in IVR, option 1 transfers call to ext 100(which works excellent)

    If ext 100 does not answer within 10 sec, call to be forwarded to mobile that is 1416xxxxxxx, i get message transfer failed error 486, line busy.

    In the out bound rule for mobile,
    1.calls to nos. starting with prefix is set to 1
    2. calls from extension is left blank
    3. calls with nos with length left blank
    4. route is set to voip provider
    5. strip digits set to 0 since the voip provider requires the no. to be dialed with 1 prefix

    I am attaching the log for your detailed diagnosis. Please help..........

    15:56:59.687 [CM503008]: Call(2): Call is terminated
    15:56:51.593 [CM503003]: Call(2): Call to sip:100@192.168.1.102:5060 has failed; Cause: 487 Request Terminated; from IP:127.0.0.1:2250
    15:56:50.984 [CM503016]: Call(2): Attempt to reach <sip:100@127.0.0.1:5060> failed. Reason: Busy
    15:56:50.984 [CM503003]: Call(2): Call to sip:1416XXXXXXX@vbuzzer.com:5060 has failed; Cause: 486 1 Busy Here!; from IP:69.172.204.133:5060
    15:56:50.796 [CM503025]: Call(2): Calling VoIPline:1416XXXXXXX@(Ln.10001@FPL)@[Dev:sip:abcd@vbuzzer.com:5060]
    15:56:50.671 [CM503005]: Call(2): Forwarding: VoIPline:1416XXXXXXX@(Ln.10001@FPL)@[Dev:sip:abcd@vbuzzer.com:5060]
    15:56:47.406 [CM505001]: Ext.100: Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [3CXPhone 4.0.13679.0] PBX contact: [sip:100@127.0.0.1:5060]
    15:56:47.406 [CM503002]: Call(2): Alerting sip:100@127.0.0.1:2250;rinstance=92e2dc84e05a27b3
    15:56:45.906 Currently active calls - 1: [2]
    15:56:45.625 [CM503025]: Call(2): Calling Ext:Ext.100@[Dev:sip:100@127.0.0.1:2250;rinstance=92e2dc84e05a27b3]
    15:56:45.578 [CM503004]: Call(2): Route 1: Ext:Ext.100@[Dev:sip:100@127.0.0.1:2250;rinstance=92e2dc84e05a27b3]
    15:56:45.562 [CM503010]: Making route(s) to <sip:100@127.0.0.1:5060>
    15:56:45.562 [CM505003]: Provider:[FPL] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [vBuzzer UA] PBX contact: [sip:abcd@173.32.114.80:52268]
    15:56:40.562 [MS211000] C:2.1: 65.39.128.70:42302 is delivering DTMF using RTP payload (RFC2833). In-Band DTMF tone detection is disabled for this call segment.
    15:56:31.578 [CM503007]: Call(2): Device joined: sip:800@127.0.0.1:40600;rinstance=5ffa1e04f7fbc3dd
    15:56:31.562 [CM503007]: Call(2): Device joined: sip:abcd@vbuzzer.com:5060
    15:56:31.546 [CM505001]: Ext.800: Device info: Device Identified: [Man: 3CX Ltd.;Mod: 3CX IVR;Rev: General] Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [3CX IVR] PBX contact: [sip:800@127.0.0.1:5060]
    15:56:31.546 [CM503002]: Call(2): Alerting sip:800@127.0.0.1:40600;rinstance=5ffa1e04f7fbc3dd
    15:56:31.343 [CM503025]: Call(2): Calling Ext:Ext.800@[Dev:sip:800@127.0.0.1:40600;rinstance=5ffa1e04f7fbc3dd]
    15:56:31.312 [CM503004]: Call(2): Route 1: Ext:Ext.800@[Dev:sip:800@127.0.0.1:40600;rinstance=5ffa1e04f7fbc3dd]
    15:56:31.312 [CM503010]: Making route(s) to <sip:800@192.168.1.102:5060>
    15:56:31.312 [CM505003]: Provider:[FPL] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [vBuzzer UA] PBX contact: [sip:abcd@173.32.114.80:52268]
    15:56:31.281 [CM503001]: Call(2): Incoming call from 647XXXXXXX@(Ln.10001@FPL) to <sip:800@192.168.1.102:5060>
    15:56:31.234 [CM503012]: Inbound out-of-office hours rule (unnamed) for 10001 forwards to DN:800
     
  14. nb

    nb Support Team
    Staff Member 3CX Support

    Joined:
    Jun 7, 2007
    Messages:
    2,129
    Likes Received:
    153
    If it was a problem related to outbound rules, you would have seen in the logs no matching outbound rule found. But in your case, your outbound rule is simple and correct so you cannot miss here.
    The problem is clearly that

    15:56:50.984 [CM503003]: Call(2): Call to sip:1416XXXXXXX@vbuzzer.com:5060 has failed; Cause: 486 1 Busy Here!; from IP:69.172.204.133:5060

    You need to make a wireshark to see what exactly is going on.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
Thread Status:
Not open for further replies.