Consult / Attended Transfer Issues with "Supports Re-Invite" enabled.

Status
Not open for further replies.

jroozee

Premier Customer
Joined
Jul 10, 2019
Messages
32
Reaction score
3
We're having issues consult/attended transferring calls. First, let me say our users are using the softphone and they're working from home remotely.

When we consult/attend transfer a call, we have intermittent problems when we have the "Supports Re-Invite" turned on. Usually the transfer dosn't go through, or no audio. When we turn it off, it works fine. However, we want it turned on so that once the transfer goes through it will show the original callers phone #. When its turned off, it only shows the extension of the person tho transferred it and it never changes.

Does anyone have any suggestions? I'm getting very frustrated.
 
Shared parking wont work for our call center needs.


  • 3CX Version. Professional Annual 16.0.619
  • Server OS, Debian 9 on Hyper-V
  • Is the 3CX Server Hosted: It's running on my server in Hyper-V. 1500MB RAM, 1 CPU Cores
  • We're using a custom built Softphone that used Ozeki SDK, however the same issue happens even if we try the 3CX Softphone
  • Provisioning Method: Local / Manual
  • Trunk Provider: 16.0.619
  • Has the Firewall Checker passed: YES
  • Are custom Phone Templates being used: NO
 
Hello @jroozee

Are you referring to the Support Re-invite option of the extensions or of the SIP trunk options? Normally the Supports Re-invite options of the extensions must be enabled and the one under the trunk settings disabled.
 
I am referring to the Support Re-Invite for extensions. PBX Delivers audio is also turned on for all extensions to ensure call recording. SIP Support Re-Invites is turned off on the the trunks.
 
Have you looked a the 3CX Activity Logs to see if there is any indication of what might be happening?

Given that these people are working from home, there are going to be many types of routers involved. Are there some users that have no issue, while others do?

Have you tried turning off recording, as a test, to see if the issue still occurs?
Are the users set to use the 3CX tunnel?
 
I have not dug that deep looking at the logs. Im sure theirs multiple routers involved, but it seems to be for all users.

I haven't tried turning off recordings, why would that make a difference?

Tunnel is not being used-- again, we're using our own in house Softphone, but issue is replicated even using 3CX Phone.
 
You said that you were using "the softphone", so I naturally assumed it was the 3CX softphone. Have you tried using that, at a location, to see if there is a different result? It might help to narrow down the cause.
 
To determine if the issue is caused by the PBX or your unsupported softphones, please use the by 3CX supported softphones.
 
As mentioned above........ I have tested using the 3CX Softphone and the same issue can be replicated.
 
Tunnel is not being used-- again, we're using our own in house Softphone, but issue is replicated even using 3CX Phone.
Didn't you use the tunnel of the 3CX app?
Which 3CX Phone are you using? iOS, Android, Windows?
Please use 3CX app with Tunnel and test again.
 
I don't see any point in trying the tunnel when we're just trying to diagnose simple SIP protocol message issues. Why compare apples to oranges? If the tunnel option did work, that doesn't fix my issue. We can't use the 3CX Softphone at the end of the day (it's integration capabilities is horrible, and our softphone is highly integrated, e.g. when a user hangs up, they're prompted with multiple call disposition codes, which automatically update the call disposition within out call-center software).

The 3CX Tunnel is it's own protocol. We are just trying to diagnose simple SIP protocol here.
 
@YiannisH - in the training session conducted by ABP (but taught by Andreas - I think) I thought he had instructed us to disable the Supports Reinvites option. Is it your recommendation that it be selected by default for local extensions? We're 100% Yealink, btw.
 
@YiannisH - in the training session conducted by ABP (but taught by Andreas - I think) I thought he had instructed us to disable the Supports Reinvites option. Is it your recommendation that it be selected by default for local extensions? We're 100% Yealink, btw.
FYI - Without the " Supports Reinvites option " enabled, when a call is transferred, the call will never be updated with the actual other callers information. So for example, if you get a inbound call that's transferred to you, the call would just show the extension of the person who transferred it. This is not good for a inbound call-center.

Supports Reinvites option can cause issues and typically is best turned off unless it's needed (like we need it).
 
@@YiannisH - in the training session conducted by ABP (but taught by Andreas - I think) I thought he had instructed us to disable the Supports Reinvites option. Is it your recommendation that it be selected by default for local extensions? We're 100% Yealink, btw.
Support Reinvites and Support Replaces should always be enabled for extensions for attended functionality to work correctly but in most cases should be disabled for VoIP providers unless needed for specific purposes (e.g. reinvites for video calls).
 
  • Like
Reactions: DSXVOICE
FYI - Without the " Supports Reinvites option " enabled, when a call is transferred, the call will never be updated with the actual other callers information. So for example, if you get a inbound call that's transferred to you, the call would just show the extension of the person who transferred it. This is not good for a inbound call-center.

Supports Reinvites option can cause issues and typically is best turned off unless it's needed (like we need it).
For blind transfers the Supports Reinvite option should not make any difference in regards to caller ID presentation. For attended transfers it is needed however.
Supports Reinvites Option on extensions does not cause issues and should generally be enabled on all extensions for supporting all functionality.

The Supports Reinvites option enables or disables the ability of the PBX to send reinvites to the specific extension. It does not limit the extension from sending reinvites to the PBX.
Having it enabled should not affect the ability to perform transfers. If you are facing issues then you should look to network issues. To troubleshoot basic SIP protocol functionality you could run a capture on the PBX and see the flow and where it goes wrong when you have reinvites enabled. You could also use the activity log to track down SIP signalling and the internal PBX process.
The reason people suggest using the 3CX client is because the tunnel can help bypass some network issues which will help you narrow down the source of the issue. I would also suggest using the 3CX webclient just for testing and see if you can replicate the issue by turning reinvites on or off.
 
Thanks. Another related issue we have is the attended transfer does go through correctly, but when the person transferring finalizing the transfer, the receiving party gets hold music. So they have to Hold and then Unhold the call in order to get the call. Doesn't happen every time though.

If we use TCP for SIP instead of UDP, I'd think things would be bettter but it actually makes it worse.

I guess I'm just going to have to do some deep log checking to narrow down the issue, if I do find an issue, what are common fixes for common issues?
 
There is really no common fixes for this as it is not a common issue. Usually things either work or they don't. When issues are intermittent like this the cause is never common. Let us know if you find something or if you need assistance deciphering the logs.
 
Status
Not open for further replies.

Forum statistics

Threads
111,955
Messages
589,926
Members
164,855
Latest member
parik24pro