Solved: Forwarding rules MAJOR bug V9

[acolville]

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.

 

[Eurylink]

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.

 

[acolville]

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!

 

[MichaelB_3CX]

Re: Forwarding rules MAJOR bug V9

Hi, what is the status of this post?
Thanks and Regards

 

[acolville]

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 [email protected] across a DIRECT bridge to [email protected]

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 IPort 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:[email protected]: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:[email protected]: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:[email protected]:5060>;party=calling

 

[LeonidasG_3CX]

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 [email protected]

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.

 

[acolville]

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 [email protected]

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.

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:[email protected]:5060;rinstance=deffda0693c8db30
15:44:13.965 [CM503007]: Call(11): Device joined: sip:[email protected]: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:[email protected]:5060]
15:44:11.549 [CM503002]: Call(11): Alerting sip:[email protected]:5060;rinstance=deffda0693c8db30
15:44:11.082 [CM503025]: Call(11): Calling PBXline:198@(Ln.10002@Kitehill-Beggars)@[Dev:sip:[email protected]: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:[email protected]: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:[email protected]: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:[email protected]:5060]
15:47:05.991 [CM503001]: Call(12): Incoming call from 10001@(Ln.10001@beggars-Woodside) to <sip:[email protected]: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.

 

[nb]

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

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

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?

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:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.6.2:5060;branch=z9hG4bK-d8754z-bb7df9178011c064-1---d8754z-;rport=5060

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 [email protected]

 

[acolville]

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!

 

[acolville]

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.

 

[kolagola]

hi,

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

Thanks,

Kola

 

[nb]

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?

 

[kolagola]

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:[email protected]: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:[email protected]:5060> failed. Reason: Busy
15:56:50.984 [CM503003]: Call(2): Call to sip:[email protected]: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:[email protected]:5060]
15:56:50.671 [CM503005]: Call(2): Forwarding: VoIPline:1416XXXXXXX@(Ln.10001@FPL)@[Dev:sip:[email protected]: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:[email protected]:5060]
15:56:47.406 [CM503002]: Call(2): Alerting sip:[email protected]: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:[email protected]:2250;rinstance=92e2dc84e05a27b3]
15:56:45.578 [CM503004]: Call(2): Route 1: Ext:Ext.100@[Dev:sip:[email protected]:2250;rinstance=92e2dc84e05a27b3]
15:56:45.562 [CM503010]: Making route(s) to <sip:[email protected]: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:[email protected]: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:[email protected]:40600;rinstance=5ffa1e04f7fbc3dd
15:56:31.562 [CM503007]: Call(2): Device joined: sip:[email protected]: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:[email protected]:5060]
15:56:31.546 [CM503002]: Call(2): Alerting sip:[email protected]:40600;rinstance=5ffa1e04f7fbc3dd
15:56:31.343 [CM503025]: Call(2): Calling Ext:Ext.800@[Dev:sip:[email protected]:40600;rinstance=5ffa1e04f7fbc3dd]
15:56:31.312 [CM503004]: Call(2): Route 1: Ext:Ext.800@[Dev:sip:[email protected]:40600;rinstance=5ffa1e04f7fbc3dd]
15:56:31.312 [CM503010]: Making route(s) to <sip:[email protected]: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:[email protected]:52268]
15:56:31.281 [CM503001]: Call(2): Incoming call from 647XXXXXXX@(Ln.10001@FPL) to <sip:[email protected]:5060>
15:56:31.234 [CM503012]: Inbound out-of-office hours rule (unnamed) for 10001 forwards to DN:800

 

[nb]

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:[email protected]: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.