Connect 2 old PBX to 3CX

[ferryblu3]

Here is my scenario to set up the 3cx phone system. But I got some problem in the setup. I have no problem in main office, I can dial to 3CX ext and dial to analog PBX from the ip phone. The gateway I use is Grandstream GXW4104 in the main office. So here is the problem.
1. In the branch, I use oivatech (i forget the type, but its old one), the registration status is success to connect 3cx, but when I try to dial from ip phone to analog pbx, I just hear the voicemail box sound. When I dial 200 from analog phone, nothing happen. I wonder what is wrong because the setting in 3cx is same with the main office. Is the oivatech not support 3cx?
2. Can I use the scenario above? So, when I dial 200 from the main branch and enter 9108, I can connect to the branch Analog phone. I try in the main office, dial 200 and then enter 8108 (108 is one of the ext in main office) but I just got the message that the number i dial (8108) is unregistered. Any additional setting for this scenario?

 

[jasit]

how did you setup the connection from the old PBX's to 3cx, was it as an extension, master bridge or voip provider? Did you create inbound routes on the 3cx system?

If you create the inbound as a master bridge, you should be able to connect your old system up to 3cx.

 

[ferryblu3]

how did you setup the connection from the old PBX's to 3cx, was it as an extension, master bridge or voip provider? Did you create inbound routes on the 3cx system?

If you create the inbound as a master bridge, you should be able to connect your old system up to 3cx.

I just use inbound and outbound rules,

in main office in working fine, but the branch not working with the same setting I apply.

 

[leejor]

Something you may need to do, and I had this happen to me a long time ago when trying to connect an analogue PBX extension to a gateway...is to check the line voltage on the PBX extensions. Some PBXs only supply 24 VDC whereas most PSTN lines supply about 48 VDC. Unless the settings have been adjusted on the gateway, it may think that the low voltage signals that the line is in use and refuse to place a call.

Post one of the 3CX Server logs of a 3CX call to Branch A.

 

[ferryblu3]

Something you may need to do, and I had this happen to me a long time ago when trying to connect an analogue PBX extension to a gateway...is to check the line voltage on the PBX extensions. Some PBXs only supply 24 VDC whereas most PSTN lines supply about 48 VDC. Unless the settings have been adjusted on the gateway, it may think that the low voltage signals that the line is in use and refuse to place a call.

Post one of the 3CX Server logs of a 3CX call to Branch A.

Here is the log:

04-Mar-2015 10:06:50.468	[CM503007]: Call(C:19): Line:10007>>108 has joined, contact <sip:[email protected]:5060>
04-Mar-2015 10:06:50.465	[CM503007]: Call(C:19): Extn:2000 has joined, contact <sip:[email protected]:63321>
04-Mar-2015 10:06:50.461	L:19.2[Line:10007>>108] has joined to L:19.1[Extn]
04-Mar-2015 10:06:50.460	[CM505002]: Gateway:[Voip Cakung] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [] PBX contact: [sip:[email protected]:5060]
04-Mar-2015 10:06:49.441	[CM503007]: Call(C:20): VMail:9999 has joined, contact <sip:[email protected]:40600>
04-Mar-2015 10:06:49.434	[CM503007]: Call(C:20): Line:10004<<10004 has joined, contact <sip:[email protected]:5060>
04-Mar-2015 10:06:49.430	L:20.2[VMail] has joined to L:20.1[Line:10004<<10004]
04-Mar-2015 10:06:49.280	[CM503025]: Call(C:20): Calling T:VMail:9999@[Dev:sip:[email protected]:40600;rinstance=01ed789f0cb53fab] for L:20.1[Line:10004<<10004]
04-Mar-2015 10:06:49.234	[CM503005]: Call(C:20): Forwarding: T:VMail:9999@[Dev:sip:[email protected]:40600;rinstance=01ed789f0cb53fab]
04-Mar-2015 10:06:49.234	L:20.1[Line:10004<<10004] forwards call from Extn:1000 to VMail:9999 based on rule Fwd[Available/NotReg]
04-Mar-2015 10:06:49.234	L:20.1[Line:10004<<10004] failed to reach Extn:1000, reason Not Registered
04-Mar-2015 10:06:49.234	[CM503017]: Call(C:20): Target is not registered: Extn:1000
04-Mar-2015 10:06:49.233	[CM505002]: Gateway:[Voip Cakung] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [] PBX contact: [sip:[email protected]:5060]
04-Mar-2015 10:06:49.231	[CM503001]: Call(C:20): Incoming call from Line:10004<<10004 to <sip:[email protected]:5060>
04-Mar-2015 10:06:49.230	Line limit check: Current # of calls for line Lc:10004(@Voip Cakung[<sip:[email protected]:5060>]) is 1; limit is 1
04-Mar-2015 10:06:49.224	[CM503012]: Inbound office hours rule (unnamed) for 10004 forwards to DN:1000
04-Mar-2015 10:06:47.233	[CM503025]: Call(C:19): Calling T:Line:10007>>108@[Dev:sip:[email protected]:5060,Dev:sip:[email protected]:5060,Dev:sip:[email protected]:5060,Dev:sip:[email protected]:5060] for L:19.1[Extn]
04-Mar-2015 10:06:47.184	[CM503027]: Call(C:19): From: Extn:2000 ("Ferry" <sip:[email protected]:5060>)  to  T:Line:10007>>108@[Dev:sip:[email protected]:5060,Dev:sip:[email protected]:5060,Dev:sip:[email protected]:5060,Dev:sip:[email protected]:5060]
04-Mar-2015 10:06:47.184	[CM503004]: Call(C:19): Route 1: from L:19.1[Extn] to T:Line:10007>>108@[Dev:sip:[email protected]:5060,Dev:sip:[email protected]:5060,Dev:sip:[email protected]:5060,Dev:sip:[email protected]:5060]
04-Mar-2015 10:06:47.184	Line limit check: Current # of calls for line Lc:10004(@Voip Cakung[<sip:[email protected]:5060>]) is 0; limit is 1
04-Mar-2015 10:06:47.184	Line limit check: Current # of calls for line Lc:10005(@Voip Cakung[<sip:[email protected]:5060>]) is 0; limit is 1
04-Mar-2015 10:06:47.184	Line limit check: Current # of calls for line Lc:10006(@Voip Cakung[<sip:[email protected]:5060>]) is 0; limit is 1
04-Mar-2015 10:06:47.184	Line limit check: Current # of calls for line Lc:10007(@Voip Cakung[<sip:[email protected]:5060>]) is 0; limit is 1
04-Mar-2015 10:06:47.184	Call(C:19): Call from Extn:2000 to 9108 matches outbound rule 'Rule for Voip Cakung'
04-Mar-2015 10:06:47.181	[CM503001]: Call(C:19): Incoming call from Extn:2000 to <sip:[email protected]:5060>

Last time it's connected to voicemail, but this time not connected to any voicemail and to the PBX extention too.

 

[leejor]

Should the port numbers for each trunk all be 5060? Have you compared this log with the one for a working call to the other gateway?

Half way up there is an incoming call from trunk 10004 which (following the rules) forwards to ext 1000, which, is not registered, so the call forwards off to voicemail as it should.

I'm assuming that this is all the same call. it is sent to the gateway, then reverts back to 3CX on a trunk. When 3CX originally sends the call, it does not seem to be selecting one particular trunk member, but all of them.

 

[ferryblu3]

Should the port numbers for each trunk all be 5060? Have you compared this log with the one for a working call to the other gateway?

Half way up there is an incoming call from trunk 10004 which (following the rules) forwards to ext 1000, which, is not registered, so the call forwards off to voicemail as it should.

I'm assuming that this is all the same call. it is sent to the gateway, then reverts back to 3CX on a trunk. When 3CX originally sends the call, it does not seem to be selecting one particular trunk member, but all of them.

this is one of the success one log,

04-Mar-2015 10:00:24.273	[CM503007]: Call(C:18): Line:10003>>108 has joined, contact <sip:[email protected]:5066>
04-Mar-2015 10:00:24.269	[CM503007]: Call(C:18): Extn:2000 has joined, contact <sip:[email protected]:63321>
04-Mar-2015 10:00:24.263	L:18.2[Line:10003>>108] has joined to L:18.1[Extn]
04-Mar-2015 10:00:24.253	[CM505002]: Gateway:[GXW4104 - Tebet] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [Grandstream GXW4104 (HW 2.1, Ch:11) 1.3.4.10] PBX contact: [sip:[email protected]:5060]
04-Mar-2015 10:00:22.395	[CM503025]: Call(C:18): Calling T:Line:10003>>108@[Dev:sip:[email protected]:5066;transport=udp,Dev:sip:[email protected]:5064;transport=udp,Dev:sip:[email protected]:5062;transport=udp,Dev:sip:[email protected]:5060;transport=udp] for L:18.1[Extn]
04-Mar-2015 10:00:22.341	[CM503027]: Call(C:18): From: Extn:2000 ("Ferry" <sip:[email protected]:5060>)  to  T:Line:10003>>108@[Dev:sip:[email protected]:5066;transport=udp,Dev:sip:[email protected]:5064;transport=udp,Dev:sip:[email protected]:5062;transport=udp,Dev:sip:[email protected]:5060;transport=udp]
04-Mar-2015 10:00:22.340	[CM503004]: Call(C:18): Route 1: from L:18.1[Extn] to T:Line:10003>>108@[Dev:sip:[email protected]:5066;transport=udp,Dev:sip:[email protected]:5064;transport=udp,Dev:sip:[email protected]:5062;transport=udp,Dev:sip:[email protected]:5060;transport=udp]
04-Mar-2015 10:00:22.340	Line limit check: Current # of calls for line Lc:10000(@GXW4104 - Tebet[<sip:[email protected]:5060>]) is 0; limit is 1
04-Mar-2015 10:00:22.340	Line limit check: Current # of calls for line Lc:10001(@GXW4104 - Tebet[<sip:[email protected]:5062>]) is 0; limit is 1
04-Mar-2015 10:00:22.340	Line limit check: Current # of calls for line Lc:10002(@GXW4104 - Tebet[<sip:[email protected]:5064>]) is 0; limit is 1
04-Mar-2015 10:00:22.340	Line limit check: Current # of calls for line Lc:10003(@GXW4104 - Tebet[<sip:[email protected]:5066>]) is 0; limit is 1
04-Mar-2015 10:00:22.340	Call(C:18): Call from Extn:2000 to 8108 matches outbound rule 'Rule for GXW4104 - Tebet'
04-Mar-2015 10:00:22.338	[CM503001]: Call(C:18): Incoming call from Extn:2000 to <sip:[email protected]:5060>
04-Mar-2015 10:00:18.825	Leg L:17.2[VMail] is terminated: Cause: BYE from PBX
04-Mar-2015 10:00:18.825	[CM503008]: Call(C:17): Call is terminated
04-Mar-2015 10:00:18.821	Leg L:17.1[Line:10004<<10004] is terminated: Cause: BYE from 192.168.3.6:5060
04-Mar-2015 10:00:18.384	Leg L:16.2[Line:10007>>108] is terminated: Cause: BYE from PBX
04-Mar-2015 10:00:18.384	[CM503008]: Call(C:16): Call is terminated
04-Mar-2015 10:00:18.379	Leg L:16.1[Extn] is terminated: Cause: BYE from 192.168.2.52:63321

I have check the setting again and again, but there is no rules I set which forward it to 1000, I wonder where this rules come from.

And about my second question in the first post, is it possible to do something like that? So, from the old PBX in brach A, I dial 200 then the ext following the rules I set, I can call the old PBX in main office.

 

[leejor]

Just a quick look over the two logs you posted

From the first log, a call that failed..

015 10:06:47.184 Line limit check: Current # of calls for line Lc:10004(@Voip Cakung[<sip:[email protected]:5060>]) is 0; limit is 1
04-Mar-2015 10:06:47.184 Line limit check: Current # of calls for line Lc:10005(@Voip Cakung[<sip:[email protected]:5060>]) is 0; limit is 1
04-Mar-2015 10:06:47.184 Line limit check: Current # of calls for line Lc:10006(@Voip Cakung[<sip:[email protected]:5060>]) is 0; limit is 1
04-Mar-2015 10:06:47.184 Line limit check: Current # of calls for line Lc:10007(@Voip Cakung[<sip:[email protected]:5060>]) is 0; limit is 1

It wouldn't cut and past the whole width, but you get the point.

And from a working call...

015 10:00:22.340 Line limit check: Current # of calls for line Lc:10000(@GXW4104 - Tebet[<sip:[email protected]:5060>]) is 0; limit is 1
04-Mar-2015 10:00:22.340 Line limit check: Current # of calls for line Lc:10001(@GXW4104 - Tebet[<sip:[email protected]:5062>]) is 0; limit is 1
04-Mar-2015 10:00:22.340 Line limit check: Current # of calls for line Lc:10002(@GXW4104 - Tebet[<sip:[email protected]:5064>]) is 0; limit is 1
04-Mar-2015 10:00:22.340 Line limit check: Current # of calls for line Lc:10003(@GXW4104 - Tebet[<sip:[email protected]:5066>]) is

Note that on the second (the working log), that each trunk, while addressed using the same IP (of the gateway) has a unique port number. On the first, they all use 5060.

Did you create a provisioning file, or manually provision the non-working gateway?

 

[ferryblu3]

I not notice about the port before, is that the problem why the Branch A is fail to make a call?
about the port setting in the gateway, I see that the working one have setting like this,

Local SIP Listen Port: ch1-4:5060++;

but the fail one don't have the ++ command,

Local SIP Port: 5060

I try to add other port, but the gateway only can input 1 port there.



I just manually provision all of them without make a file, with the same way.

 

[leejor]

Gateway addressing is handled in a different manner than ATAs, within 3CX. Where 3CX is happy with the registration information it "acquires" with an ATA, and uses that information to send calls to that device, with a gateway, 3CX needs to be told (datafilled) where to send calls, and the device settings must match (in addition to the device registering).

So..even though you have manually put settings into the gateway that say (for example) ...trunk two is 10002 and its IP is 192.168.1.25 and its (listen) port is 5062, the trunk setting in 3CX must match that, and, be correct for each of the other trunks as well.

3Cx can't address each trunk as port 5060, that might work for the first trunk, but no other.

So, check the settings in both the gateway and the 3CX trunk settings. If you already have one box working correctly, you have a guide from which to follow.

 

[ferryblu3]

but the main point is here,

11-Mar-2015 08:07:51.677 [CM503012]: Inbound office hours rule (unnamed) for 10004 forwards to DN:1000

I don't really know where this rules come from, when I check the Inbound rules, there is no rule like that, but every the branch get a call, they always get this unnamed rules. Is the port cause this?

 

[leejor]

Is extension 1000 your operator extension?

In the (specific) trunk settings, there are some "generic" rule to route incoming calls, there may be something in there. 3CX will only route a call to a destination that it is told to.

 

[ferryblu3]

I found this..

Working one is like this,

And the failed one is like this too,

It's same setting but why the only branch one do that rules, not the rules I set in outbound rules one?

 

[leejor]

This would seem to indicate that 3CX is "falling back" to the default routing for incoming calls as it is not receiving correct or valid information allowing it to make use of the DID rules you created. You might want to consider running Wireshark and comparing what is sent on both the working and non-working groups.