MiCollab for Mobile - Call goes one way audio in middle of call..

[cabarrushealth]

Hello Folks, Any feedback would be TRULY appreciated. I've spent hours trying to get this issue resolved and it seems like im trying to find a needle in a haystack. I also hope I provided all the necessary needed information. Thanks

MXe-III (Physical)
MiVoice Business - 8.0 SP2
Windstream PRI Trunks

MiCollab (Virtual - LAN)
9.1.3.202 (9.1.3 FP2?)

MiVoice Border Gateway (Virtual - DMZ)
11.0.0.294 (11.0 ?)

Fortigate 200e
SIP Helper / SIP ALG Off
Traffic Shaping - high-priority
dscp 101 110 EF (Expedited Forwarding) for IPv4 Policy and Traffic Shaper

Issue
Callers have MiCollab for Mobile on their cell phone using the softphone. Caller will dial a recipient (external call) and after 3,5,14 minutes (times are avgs) the recipient can no longer hear the caller. The caller can still hear the dialer, putting call on hold and unhold makes no difference.

If we reverse the call flow (external user calls softphone user) we've been able to reproduce the issue. In this case the external caller can't hear the softphone user after 3,5,14 minutes (times are avgs). 

It does seem that most of the calls start having this issue around 14 minutes.

Changes we've done:

Created new SIP Device Capabilities Profile
On the "Timers" Tab
Session Timer = 90
Session Timer: Local as Refresh = Yes

On the "Signaling and Header Manipulation" Tab
Disable Reliable Provisional Responses = Yes

MiCollab Deployment Profile
Softphone/MBG - Default audio codec - Best compression (G.729)

I think we're a minor version down on both MiCollab and MBG so upgrading to the latest is one option.

[sunspark]

Usually the 15-minute thing is a sign of a firewall configuration gone wrong (UDP packet drop)

and sometimes The calls are getting dropped  due to session refresh not happening

( open a carrier case)

[dilkie]

Are the micollab users connecting via MBG? Is the sip trunk also going through MBG?

if so, did you turn on the signalling trace and see if the loss of audio corresponds to a sip session refresh (re-INVITE or UPDATE).

Does MBG issue a "rtp loss" event? check the event views/logs.

[cabarrushealth]

Thanks for the feedback so far.

The MiCollab users are connecting to MGB in DMZ. I know MiCollab for Mobile uses SIP but we have PRI trunks via the 3300, I'm not sure if that answers the question?

I'm not sure if I can check those logs unless I have SIP trunking?

[cabarrushealth]

MBG   sip call terminated   terminated   Warning   Mon 21 Dec 2020 15:40:26 EST   dn:1234, call-id:9228057663e8cc65, reason:INVITE transaction timeout (dlg 2974), icp:X.X.X.X

I think those errors are lining up with the calls having the issue.

[dilkie]

obviously the problem... the call is not completing properly.

[dilkie]

the signalling trace in MBG would help diagnose the issue, you should be able to see which endpoint is not responding to the INVITE sent by MBG. It's either the micollab set or the MiVB.

[lundah]

Go into your MBG settings and ensure the "Relax set RTP checks" checkbox is selected. This allows the MBG to accept an audio stream from IP's and ports other than what was negotiated during call setup, which I've found relieves some issues like this.

[cabarrushealth]

lunda - When I enable "Relax set RTP checks" the KPML wants me to put a "Confirm KPML password" to match whats in the field currently. I'm not sure what do put here?

dilkie - Could you provide me more specifics on the signaling trace and where I would find that? Would it be in a specific log or event?

Thanks both for you feedback!

[dilkie]

things tend to move a bit... look under 'troubleshooting' 'diagnostics' 'packet trace'.

click on 'enable signalling capture', make your test call and download the pcap afterwards. open with wireshark and use "sip flows" to view all the sip dialogs, select the ones for your call (there's a call on each side of MBG, so you need to select two), use "flow sequence" to see the sip messaging in a ladder diagram.

[cabarrushealth]

thanks, ill take a look..

Can these events cause the one way audio and if so is there anything I can do to fix it?

comment:excessive jitter, rtp packets queued:30

[dilkie]

not one-way audio, just telling you that audio will be crappy due to crappy network.

[sarond]

lunda - When I enable "Relax set RTP checks" the KPML wants me to put a "Confirm KPML password" to match whats in the field currently. I'm not sure what do put here?

dilkie - Could you provide me more specifics on the signaling trace and where I would find that? Would it be in a specific log or event?

Thanks both for you feedback!

It sounds like your browser is saving passwords and trying to to fill the KPML password. Just delete it before you save.

[cabarrushealth]

You folks are awesome, thanks for all the feedback. Ill let you know how things progress..

[cabarrushealth]

dilkie, I went ahead and created a ladder diagram on one of the calls our user lost voice in. The blue call is one that ended properly and the yellow is one that had the voice issue. Left is internet, middle is MBG, right is MiVB. It looks like a Request Timeout between MGB -> MiVB but I'm not understanding the BYE before that.