• V20: 3CX Re-engineered. Get V20 for increased security, better call management, a new admin console and Windows softphone. Learn More.

Transferring a PSTN call fails (attended transfer)

Status
Not open for further replies.

AlecM

Customer
Joined
Aug 24, 2007
Messages
61
Reaction score
4
Hi.

I am still a newbie to 3CX, but have managed to get pretty much everything sorted.

However, we have a problem when my users are trying to make attended transfers. This only manifests for PSTN calls. SIP originated calls (e.g. internal extensions, or external SIP calls that come in) do not exhibit the problem.

I am using a Grandstream GXW-4104 (analogue FXO) PSTN gateway, with Grandstream BT200 handsets. I have 3 analogue lines all on the same number (this is set by our PSTN provider).

A log extract for a sample inward call (from my mobile to our PSTN number) is quoted below and I've put in bold the entries that are particularly concerning:

17:45:16.253 StratLink::eek:nHangUp [CM104001] Call(919): Ext.102 hung up call; cause: BYE; from IP:10.0.0.160
17:45:15.019 StratLink::eek:nHangUp [CM104001] Call(918): Ln:10002@0115 925 9222 hung up call; cause: BYE; from IP:10.0.0.23
17:45:11.237 CallStrategy::Transfer [CM104000] Call(919): transfer failed
17:45:11.206 StratTransfer::initialize [CM008004] Call(919): Cannot build transfer target by CfgExtLine:10002
17:45:11.206 _createSimpleCT [CM105001] Target Ln:10002@0115 925 9222 has more active calls than allowed by Administrator
17:45:11.206 StratLink::Transfer [CM104002] Call(919): transfers Ext.107 from Ext.102 to sip:[email protected]
17:45:07.425 CallLegImpl::eek:nConnected [CM103001] Call(919): Created audio channel for Ext.107 (10.0.0.167:5004) with Media Server (10.0.0.22:7058)
17:45:07.394 StratInOut::eek:nConnected [CM104005] Call(919): Setup completed for call from Ext.102 to Ext.107
17:45:07.394 CallLegImpl::eek:nConnected [CM103001] Call(919): Created audio channel for Ext.102 (10.0.0.160:5006) with Media Server (10.0.0.22:7056)
17:45:03.893 CallConf::eek:nProvisional [CM103003] Call(919): Ext.107 is ringing
17:45:03.706 CallConf::eek:nIncoming [CM103002] Call(919): Incoming call from 102 (Ext.102) to sip:[email protected]
17:44:58.315 MediaServerReporting::RTPSender [MS004000] Call(918) Ext.102: (ACTIVE): Can't send RTP stream to 0.0.0.0:5004 destination unreachable
17:44:55.987 CallLegImpl::eek:nConnected [CM103001] Call(918): Created audio channel for Ext.102 (10.0.0.160:5004) with Media Server (10.0.0.22:7054)
17:44:55.956 StratInOut::eek:nConnected [CM104005] Call(918): Setup completed for call from Ln:10002@0115 925 9222 to Ext.102
17:44:53.784 CallConf::eek:nProvisional [CM103003] Call(918): Ext.102 is ringing
17:44:48.206 MediaServerReporting::DTMFhandler [MS211000] Call(918) Ln:10002@0115 925 9222: DTMF (RTP) from 10.0.0.23:5004 arrived. in-band DTMF tone detection is turned off.
17:44:43.518 CallLegImpl::eek:nConnected [CM103001] Call(918): Created audio channel for Ln:10002@0115 925 9222 (10.0.0.23:5004) with Media Server (10.0.0.22:7052)
17:44:43.424 CallConf::eek:nIncoming [CM103002] Call(918): Incoming call from 10002 (Ln:10002@0115 925 9222) to sip:[email protected]

The method of performing an attended transfer with the BT200 is to:
1. Answer original call. (in log above, this is extension 102 answering the call)
2. Press "Flash" and dial new target extension. (in log above, this is ext. 107)
3. Ext. 107 picks up and talks to 102. Assuming they agree to take the call, then
4. 102 now presses "Transfer" to (supposedly) complete the transfer to 107.

At step 4, I get a brief "busy" tone in the earpiece for 102, which stays connected to the target extension (107 in this test). The external call remains on hold. If 102 then hangs up, the handset reminds 102 that the external call is on hold.

As mentioned above, the attended transfer process works if the originating call was internal, or came in via SIP. It is only when the call is PSTN in origin that the problem occurs, so I wonder if there is a config issue on the GXW-4104, or the extension registrations in 3CX.

(Note: I originally also couldn't do "blind" transfers of external calls either, but after changing the 3CX extensions settings "other options" for SIP ID to be the extension number, this feature was fixed.)

I don't know why the system indicates "more active calls than allowed". Certainly, the analogue PSTN gateway config only permits 1 call per analogue line. Is the 3CX system trying to connect both user extensions to the virtual extension of the PSTN line at the same time in order to perform the transfer? I can't really change this setting without causing other problems of trying to make 2 calls on one analogue line.

If I do change the virtual extension properties so that it permits 2 channels and try the test again, the log indicates that a successful transfer has occured, when in fact it doesn't - the final target handset gets some sort of audio loop-back occuring, and still sees the first extension's number. Also, the external extension hangs up part way through the transfer.

18:29:01.633 StratLink::eek:nHangUp [CM104001] Call(925): Ext.103 hung up call; cause: BYE; from IP:10.0.0.161
18:28:41.679 CallLegImpl::eek:nConnected [CM103001] Call(925): Created audio channel for Ext.103 (10.0.0.161:5006) with Media Server (10.0.0.22:7086)
18:28:41.679 StratTransfer::finishTransfer [CM108005] Call(925): Transfer finished, Ext.103 is connected to Ln:10002@0115 925 9222
18:28:41.679 StratTransfer::eek:nConnected [CM108001] Call(925): transfer successful, Ext.103 is connected to Ln:10002@0115 925 9222
18:28:41.054 CallLegImpl::eek:nConnected [CM103001] Call(925): Created audio channel for Ln:10002@0115 925 9222 (10.0.0.23:5020) with Media Server (10.0.0.22:7084)
18:28:40.507 StratLink::eek:nHangUp [CM104001] Call(924): Ln:10002@0115 925 9222 hung up call; cause: BYE; from IP:10.0.0.23
18:28:40.414 StratLink::Transfer [CM104002] Call(925): transfers Ext.103 from Ext.102 to sip:[email protected]
18:28:36.273 CallLegImpl::eek:nConnected [CM103001] Call(925): Created audio channel for Ext.103 (10.0.0.161:5004) with Media Server (10.0.0.22:7082)
18:28:36.257 StratInOut::eek:nConnected [CM104005] Call(925): Setup completed for call from Ext.102 to Ext.103
18:28:36.257 CallLegImpl::eek:nConnected [CM103001] Call(925): Created audio channel for Ext.102 (10.0.0.160:5006) with Media Server (10.0.0.22:7080)
18:28:32.804 CallConf::eek:nProvisional [CM103003] Call(925): Ext.103 is ringing
18:28:32.601 CallConf::eek:nIncoming [CM103002] Call(925): Incoming call from 102 (Ext.102) to sip:[email protected]
18:28:29.991 MediaServerReporting::RTPSender [MS004000] Call(924) Ext.102: (ACTIVE): Can't send RTP stream to 0.0.0.0:5004 destination unreachable
18:28:27.007 CallLegImpl::eek:nConnected [CM103001] Call(924): Created audio channel for Ext.102 (10.0.0.160:5004) with Media Server (10.0.0.22:7078)
18:28:26.976 StratInOut::eek:nConnected [CM104005] Call(924): Setup completed for call from Ln:10002@0115 925 9222 to Ext.102
18:28:25.663 CallConf::eek:nProvisional [CM103003] Call(924): Ext.102 is ringing
18:28:20.585 MediaServerReporting::DTMFhandler [MS211000] Call(924) Ln:10002@0115 925 9222: DTMF (RTP) from 10.0.0.23:5016 arrived. in-band DTMF tone detection is turned off.
18:28:17.054 CallLegImpl::eek:nConnected [CM103001] Call(924): Created audio channel for Ln:10002@0115 925 9222 (10.0.0.23:5016) with Media Server (10.0.0.22:7076)
18:28:16.960 CallConf::eek:nIncoming [CM103002] Call(924): Incoming call from 10002 (Ln:10002@0115 925 9222) to sip:[email protected]

There are a couple of other items in the first log I would appreciate guidance on, which may be related:
"in-band DTMF tone detection is turned off"
I believe I have gone through everything and cannot find where this is being determined. DTMF is being transmitted from the 4104, as it's needed to operate the 3CX DR menu.

Also:
Can't send RTP stream to 0.0.0.0:5004
The port 5004 setting is correct and matches what each BT200 config has, but I don't uderstand why 3CX keeps trying to use IP address 0.0.0.0 instead of the handset address it already knows (fixed IP addresses are being used for all telephony devices).

What I've tried:
For each extension, disabling "Supports Re-invite" and "Supports Replaces header". This made no difference.

Then for the FXO gateway, enabling "Supports Re-invite" and "Supports Replaces header". This made no difference.

I would really appreciate any help on getting this feature working properly. I devised a work-around, by using an attended transfer, then recovering the call, then doing a blind transfer afterwards, but this is obviously a bit of a cludge fix and quite clunky for my users to remember!

Thanks for any input.

Al
 
AlecM said:
Hi.

I am still a newbie to 3CX, but have managed to get pretty much everything sorted.

However, we have a problem when my users are trying to make attended transfers. This only manifests for PSTN calls. SIP originated calls (e.g. internal extensions, or external SIP calls that come in) do not exhibit the problem.

I am using a Grandstream GXW-4104 (analogue FXO) PSTN gateway, with Grandstream BT200 handsets. I have 3 analogue lines all on the same number (this is set by our PSTN provider).

A log extract for a sample inward call (from my mobile to our PSTN number) is quoted below and I've put in bold the entries that are particularly concerning:

17:45:16.253 StratLink::eek:nHangUp [CM104001] Call(919): Ext.102 hung up call; cause: BYE; from IP:10.0.0.160
17:45:15.019 StratLink::eek:nHangUp [CM104001] Call(918): Ln:10002@0115 925 9222 hung up call; cause: BYE; from IP:10.0.0.23
17:45:11.237 CallStrategy::Transfer [CM104000] Call(919): transfer failed
17:45:11.206 StratTransfer::initialize [CM008004] Call(919): Cannot build transfer target by CfgExtLine:10002
17:45:11.206 _createSimpleCT [CM105001] Target Ln:10002@0115 925 9222 has more active calls than allowed by Administrator
17:45:11.206 StratLink::Transfer [CM104002] Call(919): transfers Ext.107 from Ext.102 to sip:[email protected]
17:45:07.425 CallLegImpl::eek:nConnected [CM103001] Call(919): Created audio channel for Ext.107 (10.0.0.167:5004) with Media Server (10.0.0.22:7058)
17:45:07.394 StratInOut::eek:nConnected [CM104005] Call(919): Setup completed for call from Ext.102 to Ext.107
17:45:07.394 CallLegImpl::eek:nConnected [CM103001] Call(919): Created audio channel for Ext.102 (10.0.0.160:5006) with Media Server (10.0.0.22:7056)
17:45:03.893 CallConf::eek:nProvisional [CM103003] Call(919): Ext.107 is ringing
17:45:03.706 CallConf::eek:nIncoming [CM103002] Call(919): Incoming call from 102 (Ext.102) to sip:[email protected]
17:44:58.315 MediaServerReporting::RTPSender [MS004000] Call(918) Ext.102: (ACTIVE): Can't send RTP stream to 0.0.0.0:5004 destination unreachable
17:44:55.987 CallLegImpl::eek:nConnected [CM103001] Call(918): Created audio channel for Ext.102 (10.0.0.160:5004) with Media Server (10.0.0.22:7054)
17:44:55.956 StratInOut::eek:nConnected [CM104005] Call(918): Setup completed for call from Ln:10002@0115 925 9222 to Ext.102
17:44:53.784 CallConf::eek:nProvisional [CM103003] Call(918): Ext.102 is ringing
17:44:48.206 MediaServerReporting::DTMFhandler [MS211000] Call(918) Ln:10002@0115 925 9222: DTMF (RTP) from 10.0.0.23:5004 arrived. in-band DTMF tone detection is turned off.
17:44:43.518 CallLegImpl::eek:nConnected [CM103001] Call(918): Created audio channel for Ln:10002@0115 925 9222 (10.0.0.23:5004) with Media Server (10.0.0.22:7052)
17:44:43.424 CallConf::eek:nIncoming [CM103002] Call(918): Incoming call from 10002 (Ln:10002@0115 925 9222) to sip:[email protected]

The method of performing an attended transfer with the BT200 is to:
1. Answer original call. (in log above, this is extension 102 answering the call)
2. Press "Flash" and dial new target extension. (in log above, this is ext. 107)
3. Ext. 107 picks up and talks to 102. Assuming they agree to take the call, then
4. 102 now presses "Transfer" to (supposedly) complete the transfer to 107.

At step 4, I get a brief "busy" tone in the earpiece for 102, which stays connected to the target extension (107 in this test). The external call remains on hold. If 102 then hangs up, the handset reminds 102 that the external call is on hold.

As mentioned above, the attended transfer process works if the originating call was internal, or came in via SIP. It is only when the call is PSTN in origin that the problem occurs, so I wonder if there is a config issue on the GXW-4104, or the extension registrations in 3CX.

(Note: I originally also couldn't do "blind" transfers of external calls either, but after changing the 3CX extensions settings "other options" for SIP ID to be the extension number, this feature was fixed.)

I don't know why the system indicates "more active calls than allowed". Certainly, the analogue PSTN gateway config only permits 1 call per analogue line. Is the 3CX system trying to connect both user extensions to the virtual extension of the PSTN line at the same time in order to perform the transfer? I can't really change this setting without causing other problems of trying to make 2 calls on one analogue line.

If I do change the virtual extension properties so that it permits 2 channels and try the test again, the log indicates that a successful transfer has occured, when in fact it doesn't - the final target handset gets some sort of audio loop-back occuring, and still sees the first extension's number. Also, the external extension hangs up part way through the transfer.

18:29:01.633 StratLink::eek:nHangUp [CM104001] Call(925): Ext.103 hung up call; cause: BYE; from IP:10.0.0.161
18:28:41.679 CallLegImpl::eek:nConnected [CM103001] Call(925): Created audio channel for Ext.103 (10.0.0.161:5006) with Media Server (10.0.0.22:7086)
18:28:41.679 StratTransfer::finishTransfer [CM108005] Call(925): Transfer finished, Ext.103 is connected to Ln:10002@0115 925 9222
18:28:41.679 StratTransfer::eek:nConnected [CM108001] Call(925): transfer successful, Ext.103 is connected to Ln:10002@0115 925 9222
18:28:41.054 CallLegImpl::eek:nConnected [CM103001] Call(925): Created audio channel for Ln:10002@0115 925 9222 (10.0.0.23:5020) with Media Server (10.0.0.22:7084)
18:28:40.507 StratLink::eek:nHangUp [CM104001] Call(924): Ln:10002@0115 925 9222 hung up call; cause: BYE; from IP:10.0.0.23
18:28:40.414 StratLink::Transfer [CM104002] Call(925): transfers Ext.103 from Ext.102 to sip:[email protected]
18:28:36.273 CallLegImpl::eek:nConnected [CM103001] Call(925): Created audio channel for Ext.103 (10.0.0.161:5004) with Media Server (10.0.0.22:7082)
18:28:36.257 StratInOut::eek:nConnected [CM104005] Call(925): Setup completed for call from Ext.102 to Ext.103
18:28:36.257 CallLegImpl::eek:nConnected [CM103001] Call(925): Created audio channel for Ext.102 (10.0.0.160:5006) with Media Server (10.0.0.22:7080)
18:28:32.804 CallConf::eek:nProvisional [CM103003] Call(925): Ext.103 is ringing
18:28:32.601 CallConf::eek:nIncoming [CM103002] Call(925): Incoming call from 102 (Ext.102) to sip:[email protected]
18:28:29.991 MediaServerReporting::RTPSender [MS004000] Call(924) Ext.102: (ACTIVE): Can't send RTP stream to 0.0.0.0:5004 destination unreachable
18:28:27.007 CallLegImpl::eek:nConnected [CM103001] Call(924): Created audio channel for Ext.102 (10.0.0.160:5004) with Media Server (10.0.0.22:7078)
18:28:26.976 StratInOut::eek:nConnected [CM104005] Call(924): Setup completed for call from Ln:10002@0115 925 9222 to Ext.102
18:28:25.663 CallConf::eek:nProvisional [CM103003] Call(924): Ext.102 is ringing
18:28:20.585 MediaServerReporting::DTMFhandler [MS211000] Call(924) Ln:10002@0115 925 9222: DTMF (RTP) from 10.0.0.23:5016 arrived. in-band DTMF tone detection is turned off.
18:28:17.054 CallLegImpl::eek:nConnected [CM103001] Call(924): Created audio channel for Ln:10002@0115 925 9222 (10.0.0.23:5016) with Media Server (10.0.0.22:7076)
18:28:16.960 CallConf::eek:nIncoming [CM103002] Call(924): Incoming call from 10002 (Ln:10002@0115 925 9222) to sip:[email protected]

There are a couple of other items in the first log I would appreciate guidance on, which may be related:
"in-band DTMF tone detection is turned off"
I believe I have gone through everything and cannot find where this is being determined. DTMF is being transmitted from the 4104, as it's needed to operate the 3CX DR menu.

Also:
Can't send RTP stream to 0.0.0.0:5004
The port 5004 setting is correct and matches what each BT200 config has, but I don't uderstand why 3CX keeps trying to use IP address 0.0.0.0 instead of the handset address it already knows (fixed IP addresses are being used for all telephony devices).

What I've tried:
For each extension, disabling "Supports Re-invite" and "Supports Replaces header". This made no difference.

Then for the FXO gateway, enabling "Supports Re-invite" and "Supports Replaces header". This made no difference.

I would really appreciate any help on getting this feature working properly. I devised a work-around, by using an attended transfer, then recovering the call, then doing a blind transfer afterwards, but this is obviously a bit of a cludge fix and quite clunky for my users to remember!

Thanks for any input.

Al

Bind your gateway to the media server, and make sure phones are unbound. If you want sample settings, I'd be happy to send you mine, as I have a very similar configuration (SPA922 and GXW-4108)
-Ryan
 
Hi AlecM,

Your may try to changed the Maximum simultaneous calls from 1 to 3 at
Line(s) Configuration > PSTN Lines XXXXXX on GXW4104 > Other Options

This setting should be help to solve your issue. Try then let us know the result.
 
Thanks Ryan and Ricky for your replies.

Ryan: I have tried the settings you suggested, but this didn't help. Perhaps due to a difference in the hardware/firmware.

Ricky: I did try upping the channels to 2, but the call was disconnected in mid-transfer (the log showing this is my first post). I will experiment with upping the channels to 3, but I am concerned that this may lead to more adverse effects as analogue PSTN can only take the one channel in actual use.

I don't want to end up with the system attempting to connect 3 people to the same PSTN extension - it obviously won't work. But I will give it a go (out of business hours!)

Kind regards,

Al
 
Hi
I too am new here, and have the same problem, using 4 lines to a Patton 4114 Gateway and snom 300 handsets. I would like to try the sollutions offered but how do I bind the gateway to the media server
Regs

AlecM said:
Hi.

I am still a newbie to 3CX, but have managed to get pretty much everything sorted.

However, we have a problem when my users are trying to make attended transfers. This only manifests for PSTN calls. SIP originated calls (e.g. internal extensions, or external SIP calls that come in) do not exhibit the problem.

I am using a Grandstream GXW-4104 (analogue FXO) PSTN gateway, with Grandstream BT200 handsets. I have 3 analogue lines all on the same number (this is set by our PSTN provider).

A log extract for a sample inward call (from my mobile to our PSTN number) is quoted below and I've put in bold the entries that are particularly concerning:

17:45:16.253 StratLink::eek:nHangUp [CM104001] Call(919): Ext.102 hung up call; cause: BYE; from IP:10.0.0.160
17:45:15.019 StratLink::eek:nHangUp [CM104001] Call(918): Ln:10002@0115 925 9222 hung up call; cause: BYE; from IP:10.0.0.23
17:45:11.237 CallStrategy::Transfer [CM104000] Call(919): transfer failed
17:45:11.206 StratTransfer::initialize [CM008004] Call(919): Cannot build transfer target by CfgExtLine:10002
17:45:11.206 _createSimpleCT [CM105001] Target Ln:10002@0115 925 9222 has more active calls than allowed by Administrator
17:45:11.206 StratLink::Transfer [CM104002] Call(919): transfers Ext.107 from Ext.102 to sip:[email protected]
17:45:07.425 CallLegImpl::eek:nConnected [CM103001] Call(919): Created audio channel for Ext.107 (10.0.0.167:5004) with Media Server (10.0.0.22:7058)
17:45:07.394 StratInOut::eek:nConnected [CM104005] Call(919): Setup completed for call from Ext.102 to Ext.107
17:45:07.394 CallLegImpl::eek:nConnected [CM103001] Call(919): Created audio channel for Ext.102 (10.0.0.160:5006) with Media Server (10.0.0.22:7056)
17:45:03.893 CallConf::eek:nProvisional [CM103003] Call(919): Ext.107 is ringing
17:45:03.706 CallConf::eek:nIncoming [CM103002] Call(919): Incoming call from 102 (Ext.102) to sip:[email protected]
17:44:58.315 MediaServerReporting::RTPSender [MS004000] Call(918) Ext.102: (ACTIVE): Can't send RTP stream to 0.0.0.0:5004 destination unreachable
17:44:55.987 CallLegImpl::eek:nConnected [CM103001] Call(918): Created audio channel for Ext.102 (10.0.0.160:5004) with Media Server (10.0.0.22:7054)
17:44:55.956 StratInOut::eek:nConnected [CM104005] Call(918): Setup completed for call from Ln:10002@0115 925 9222 to Ext.102
17:44:53.784 CallConf::eek:nProvisional [CM103003] Call(918): Ext.102 is ringing
17:44:48.206 MediaServerReporting::DTMFhandler [MS211000] Call(918) Ln:10002@0115 925 9222: DTMF (RTP) from 10.0.0.23:5004 arrived. in-band DTMF tone detection is turned off.
17:44:43.518 CallLegImpl::eek:nConnected [CM103001] Call(918): Created audio channel for Ln:10002@0115 925 9222 (10.0.0.23:5004) with Media Server (10.0.0.22:7052)
17:44:43.424 CallConf::eek:nIncoming [CM103002] Call(918): Incoming call from 10002 (Ln:10002@0115 925 9222) to sip:[email protected]

The method of performing an attended transfer with the BT200 is to:
1. Answer original call. (in log above, this is extension 102 answering the call)
2. Press "Flash" and dial new target extension. (in log above, this is ext. 107)
3. Ext. 107 picks up and talks to 102. Assuming they agree to take the call, then
4. 102 now presses "Transfer" to (supposedly) complete the transfer to 107.

At step 4, I get a brief "busy" tone in the earpiece for 102, which stays connected to the target extension (107 in this test). The external call remains on hold. If 102 then hangs up, the handset reminds 102 that the external call is on hold.

As mentioned above, the attended transfer process works if the originating call was internal, or came in via SIP. It is only when the call is PSTN in origin that the problem occurs, so I wonder if there is a config issue on the GXW-4104, or the extension registrations in 3CX.

(Note: I originally also couldn't do "blind" transfers of external calls either, but after changing the 3CX extensions settings "other options" for SIP ID to be the extension number, this feature was fixed.)

I don't know why the system indicates "more active calls than allowed". Certainly, the analogue PSTN gateway config only permits 1 call per analogue line. Is the 3CX system trying to connect both user extensions to the virtual extension of the PSTN line at the same time in order to perform the transfer? I can't really change this setting without causing other problems of trying to make 2 calls on one analogue line.

If I do change the virtual extension properties so that it permits 2 channels and try the test again, the log indicates that a successful transfer has occured, when in fact it doesn't - the final target handset gets some sort of audio loop-back occuring, and still sees the first extension's number. Also, the external extension hangs up part way through the transfer.

18:29:01.633 StratLink::eek:nHangUp [CM104001] Call(925): Ext.103 hung up call; cause: BYE; from IP:10.0.0.161
18:28:41.679 CallLegImpl::eek:nConnected [CM103001] Call(925): Created audio channel for Ext.103 (10.0.0.161:5006) with Media Server (10.0.0.22:7086)
18:28:41.679 StratTransfer::finishTransfer [CM108005] Call(925): Transfer finished, Ext.103 is connected to Ln:10002@0115 925 9222
18:28:41.679 StratTransfer::eek:nConnected [CM108001] Call(925): transfer successful, Ext.103 is connected to Ln:10002@0115 925 9222
18:28:41.054 CallLegImpl::eek:nConnected [CM103001] Call(925): Created audio channel for Ln:10002@0115 925 9222 (10.0.0.23:5020) with Media Server (10.0.0.22:7084)
18:28:40.507 StratLink::eek:nHangUp [CM104001] Call(924): Ln:10002@0115 925 9222 hung up call; cause: BYE; from IP:10.0.0.23
18:28:40.414 StratLink::Transfer [CM104002] Call(925): transfers Ext.103 from Ext.102 to sip:[email protected]
18:28:36.273 CallLegImpl::eek:nConnected [CM103001] Call(925): Created audio channel for Ext.103 (10.0.0.161:5004) with Media Server (10.0.0.22:7082)
18:28:36.257 StratInOut::eek:nConnected [CM104005] Call(925): Setup completed for call from Ext.102 to Ext.103
18:28:36.257 CallLegImpl::eek:nConnected [CM103001] Call(925): Created audio channel for Ext.102 (10.0.0.160:5006) with Media Server (10.0.0.22:7080)
18:28:32.804 CallConf::eek:nProvisional [CM103003] Call(925): Ext.103 is ringing
18:28:32.601 CallConf::eek:nIncoming [CM103002] Call(925): Incoming call from 102 (Ext.102) to sip:[email protected]
18:28:29.991 MediaServerReporting::RTPSender [MS004000] Call(924) Ext.102: (ACTIVE): Can't send RTP stream to 0.0.0.0:5004 destination unreachable
18:28:27.007 CallLegImpl::eek:nConnected [CM103001] Call(924): Created audio channel for Ext.102 (10.0.0.160:5004) with Media Server (10.0.0.22:7078)
18:28:26.976 StratInOut::eek:nConnected [CM104005] Call(924): Setup completed for call from Ln:10002@0115 925 9222 to Ext.102
18:28:25.663 CallConf::eek:nProvisional [CM103003] Call(924): Ext.102 is ringing
18:28:20.585 MediaServerReporting::DTMFhandler [MS211000] Call(924) Ln:10002@0115 925 9222: DTMF (RTP) from 10.0.0.23:5016 arrived. in-band DTMF tone detection is turned off.
18:28:17.054 CallLegImpl::eek:nConnected [CM103001] Call(924): Created audio channel for Ln:10002@0115 925 9222 (10.0.0.23:5016) with Media Server (10.0.0.22:7076)
18:28:16.960 CallConf::eek:nIncoming [CM103002] Call(924): Incoming call from 10002 (Ln:10002@0115 925 9222) to sip:[email protected]

There are a couple of other items in the first log I would appreciate guidance on, which may be related:
"in-band DTMF tone detection is turned off"
I believe I have gone through everything and cannot find where this is being determined. DTMF is being transmitted from the 4104, as it's needed to operate the 3CX DR menu.

Also:
Can't send RTP stream to 0.0.0.0:5004
The port 5004 setting is correct and matches what each BT200 config has, but I don't uderstand why 3CX keeps trying to use IP address 0.0.0.0 instead of the handset address it already knows (fixed IP addresses are being used for all telephony devices).

What I've tried:
For each extension, disabling "Supports Re-invite" and "Supports Replaces header". This made no difference.

Then for the FXO gateway, enabling "Supports Re-invite" and "Supports Replaces header". This made no difference.

I would really appreciate any help on getting this feature working properly. I devised a work-around, by using an attended transfer, then recovering the call, then doing a blind transfer afterwards, but this is obviously a bit of a cludge fix and quite clunky for my users to remember!

Thanks for any input.

Al
 
Hi Paul,

To bind the gateway to the media server, open your 3CX admin webpage, then select Lines -> Manage.

Once there, click on any of the links that are for your gateway (mine are listed using the PSTN number). These are listed under the Gateway/Provider Name column.

Once the detail page for the gateway is displayed, expand the Other Options panel and check the PBX delivers audio box, then save the change by clicking OK at the bottom ofthe page.

Alec
 
Hi.

Another setting I have found impacts PSTN call transfers - at least with my particular equipment.

My setup is:
  • Grandstream GXW-4104 FXO gateway (1 of)
    Grandstream BT200 handsets (14 of these)
    3CX version 3.1.2434.0
For blind transfers from the GXW-4104, the setting in 3CX for gateway capabilities has an impact.

In the 3CX gateway capabilities, enabling Supports Re-Invite and Supports "Replaces" header stops blind transfers operating.

Note, that in order for my equipment to perform blind transfers, I also had to edit each extension so that the SIP ID is set to the same as the extension number.

Alec
 
Many thanks for that, I'll give it a whirl
Regs
Paul
 
My office did have the Grandstream GXW-4104 and a BT-200 phone (we switched to a completely different set-up due to audio quality issues), we also had problems with transfers. This is the set-up that I found worked for us...

In the gateway under Channels set the DTMF methods to ch1-4:2.

In the BT-200 under Account - Send DTMF check the via RTP(RFC2833) box.

In 3CX under manage extensions - other options check the following boxes, bind to media server, supports Re-invite, and Supports 'Replaces' header.

Also in the 3CX under manage lines - edit gateway - other options... the PBX delivers audio is not checked, "Caller-ID is in 'user' part of (one of the following)" check the 'From' field, and in the "Called-Number (for in-bound calls) is in" check the 'To User' field.

With these things checked/unchecked blind and attended transfers worked great. I hope this helps.
 
Hi all,

In response to Ricky's suggestion, I have now tried setting simultaneous calls (channels) for the virtual extensions to 3, though this did not work immediately.
I also had to un-bind the gateway from the PBX for audio, as per the suggestion by Laura Langston.

This has cured that problem and I can now attended transfer both internal SIP-only calls as well as PSTN originated calls. (that is, making this setting didn't break anything else)

Just for completeness of notes - I did test getting all three of my actual PSTN lines busy on calls and then attempting a 4th call from internal extension to an external number - this 4th call just got a "busy" signal from the 3CX server, which is as expected.

Thanks everyone!

Kind regards,

Alec
 
I am glad that everything worked out for you. Even though we are no longer using the Grandstream products I do still have copies of the configurations that we used for the GXW-4104 gateway, the Grandstream 2000 Enterprise phone, the BT-200 phone and the HT-286 converter as well as the 3CX configuration that we used for the Grandstream products and I will be glad to help you in any way that I can with future questions.
 
Status
Not open for further replies.

Getting Started - Admin

Latest Posts

Forum statistics

Threads
141,618
Messages
748,853
Members
144,730
Latest member
Ilyass.b
Get 3CX - Absolutely Free!

Link up your team and customers Phone System Live Chat Video Conferencing

Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.

3CX
A 3CX Account with that email already exists. You will be redirected to the Customer Portal to sign in or reset your password if you've forgotten it.