Mitel 3300/MiVoice Business - Calls answering into on hold status

[k123s456]

Hi,

We've had the below symptom reported by multiple users:
-External caller calls a ring group
-Internal agent answers call
-Call is immediately put on hold, and is unable to be taken off (pause symbol appears next to caller number, and hold button is greyed out and unable to be pressed)

Background info:
-Mitel 3300
-SBC is a Ribbon Sonus SWE Edge
-Users use softphone via the MiCollab desktop / mobile phone app.
-The Trunk provider has already had a look over at their end and can't see anything unusual.
-Have also raised a case with the ISP as we have had wider issues recently and they report no issues on the line.
-Recently disabled Silence Supression on the SBC, but this symptom was occurring before the change was made.
-Ring group is set to "Ring All"
-I have been generating logs from the SBC to LX for a while now, and have not been able to identify anything of interest.
I do have a suspicion this may be someone else picking up the call and essentially "beating" the other agent to picking up the call, then when they answer there is nothing there for them to grab. 
If anyone has any ideas on what this may be or best next steps that would be great. Thanks!

[ralph]

If you check the SMDR records you'll be able to see if someone else is picking up the call before answer.
I wouldn't suspect that.
You can also use the maintenance command STAT MLS <PLID> of the answering device. If the line say i_hold then the call is holding on that phone. If it says U_hold then it's on hold on another device.

My first guess though would be something in the SIP Peer configuration causing it.
You'll need to capture the SIP trace in order to find out.

Ralph

[bioreit]

Is it safe to assume that internal calls to the ring group don't get put on hold? And that direct internal and external calls to the softphones are also both ok? That it's only external calls to a ring group answered by a softphone which can get put on hold and can't be resumed?

It would potentially be worth exploring the codecs being used; I've not seen a call auto-hold or refuse to be resumed before, but I've had a lot of weird stuff happen when there's a codec mismatch, particularly when a call passes through external to internal via another hop (Ring Group, Attendant, Call transfer).
Just had a thought on this:
On the MiVBs, go to System Options and check the Number of Forward Hops. If it's too low then calls might get dropped after working their way to the softphones? Kind of doubt it would present in that way with a call being ghost-held rather than just dropping completely, but worth checking. We have ours set to 4 but think the default is 2?


BIG CAVEAT HERE: if you're not sure/familiar with changing the settings I'm referencing below, definitely don't poke first! If you must poke them, keep a detailed log of what you're changing and try to only change one or two things at once, test, then restore immediately if unsuccessful.

In MiCollab, go to:

Applications --> MiCollab Client Deployment

Across the top click on Deployment Profiles and select the edit pencil next to the profile being used

Scroll down to Softphone Settings and verify the Default audio codec in both 'columns' - PBX type and Teleworker type. (ours is set to Standard EU (G.711 A-law)


On your SIP MBG(s) go to:

Applications --> MiVoice Border Gateway

Across the top click System and then Settings

Under both the MiNet options and SIP options sections, make sure that Codec support has the MiCollab codec listed.


While you're checking both, would also be worth verifying everything else is consistent, RTP or SRTP mode, SIP transport protocol (TLS, TCP/PSK), etc.

Would also say

SIP MBG(s): under MiNet options and SIP options check if you're using Device <-> device local streaming and/or device <-> trunk local streaming. We don't use either but this will depend on how you have things setup so if you're using them that's not necessarily bad (and if you're not using them then that's not necessarily bad either).

MiCollab: under Softphone Settings check the SIP DTMF method is correct. Verify against the MiVB SIP Device Capabilities used by your softphone clients under Signaling and Header Manipulation (CoS 64 for us)


Lastly, on the MiVoice Business: Check the SIP Device Capabilities settings, particularly SDP Options and Signaling and Header Manipulation. Particularly M-Lines and Media Renegotiation/Codec entries.

Also on the MiVBs: Check Class of Service for the Ring Groups (verify the specific CoS assigned to one or more of the known-affected groups first - been bitten before when a colleague mis-assigned the incorrect CoS to a group!). There are loads of options here, so if nothing leaps out and you're not sure, feel free to paste all the CoS settings you have under General and Advanced and I can take a look at some point.

[Gambler]

Does the inbound call start to NuPoint Call Director MB.   

[k123s456]

@Gambler - yes it does

@Bioreit - will take a look, thank you!