1
Mitel MiVoice Business/MCD/3300 / Re: Mitel 3300/MiVoice Business - Calls answering into on hold status
« on: December 11, 2023, 09:49:59 AM »
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.
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.