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:
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.
There are a couple of other items in the first log I would appreciate guidance on, which may be related:
Also:
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
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:nHangUp [CM104001] Call(919): Ext.102 hung up call; cause: BYE; from IP:10.0.0.160
17:45:15.019 StratLink: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: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:nConnected [CM104005] Call(919): Setup completed for call from Ext.102 to Ext.107
17:45:07.394 CallLegImpl: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:nProvisional [CM103003] Call(919): Ext.107 is ringing
17:45:03.706 CallConf: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: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:nConnected [CM104005] Call(918): Setup completed for call from Ln:10002@0115 925 9222 to Ext.102
17:44:53.784 CallConf:nProvisional [CM103003] Call(918): Ext.102 is ringing
17:44:48.206 MediaServerReporting:TMFhandler [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: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: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:nHangUp [CM104001] Call(925): Ext.103 hung up call; cause: BYE; from IP:10.0.0.161
18:28:41.679 CallLegImpl: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:nConnected [CM108001] Call(925): transfer successful, Ext.103 is connected to Ln:10002@0115 925 9222
18:28:41.054 CallLegImpl: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: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: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:nConnected [CM104005] Call(925): Setup completed for call from Ext.102 to Ext.103
18:28:36.257 CallLegImpl: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:nProvisional [CM103003] Call(925): Ext.103 is ringing
18:28:32.601 CallConf: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: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:nConnected [CM104005] Call(924): Setup completed for call from Ln:10002@0115 925 9222 to Ext.102
18:28:25.663 CallConf:nProvisional [CM103003] Call(924): Ext.102 is ringing
18:28:20.585 MediaServerReporting:TMFhandler [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: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: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:
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."in-band DTMF tone detection is turned off"
Also:
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).Can't send RTP stream to 0.0.0.0:5004
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