Mitel Forums - The Unofficial Source
Mitel Forums => Mitel Software Applications => Topic started by: cabarrushealth on December 21, 2020, 02:27:58 PM
-
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.
-
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)
-
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.
-
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?
-
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.
-
obviously the problem... the call is not completing properly.
-
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.
-
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.
-
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!
-
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.
-
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
-
not one-way audio, just telling you that audio will be crappy due to crappy network.
-
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.
-
You folks are awesome, thanks for all the feedback. Ill let you know how things progress..
-
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.
-
the UPDATE sent to the internet did not get a response (200 OK), so after the sip timeout (32 seconds), MBG terminated the call with that BYE (which likely got lost) and also terminated the call on the MiVB side. Though I would have thought the 408 would have preceeded the BYE.. but whatever, the call terminated because the set did not respond.
Since the set is likely behind NAT (is it?) then it's possible that the NAT bindings at the far end's router timed out and the UPDATE was not forwarded to the set.
Is OPTIONS keepalive turn on in MBG?
Also, using TCP or TLS transport, rather than UDP, helps in these situations if it's possible to reconfigure your set for that.
-
Thanks for the quick reply, I didn't pay attention to the timestamps so what you say makes sense.
It does look like its behind a NAT as the Connection IP and Registration IP are different under SIP profiles and devices.
Send options keepalives is set to "Only behind a NAT" but should I change it to "Always" ?
The transport for the set is set to TLS under SIP profiles and devices. Under System -> Settings UDP and TCP Protocols are checks as well as TCP/TLS though. Does it look like its set to UDP? Thanks
-
no, "only behind NAT" should be fine. The signaling trace doesn't record OPTIONS as that just muddies things up.
If the set is configured for TLS, it *should* be fine (unless there is a set issue, and that may be the case).
I'd try configuring the set for TCP and see if that makes a difference. If you get a "global tcpdump" for the test call, you can use wireshark to analyse it. With TLS, the sip messaging can't be seen so it's much harder to see what's going on. The "signalling capture" is internal to mbg, it gets the sip messages *after* decryption (or before encryption) and writes out a "fake" pcap for analysis, but it isn't actually showing what was on the wire and the state of the connection, like the global tcpdump does. (if you look closely, all the packets are udp in the signalling pcap, even though the actual connection may be tcp or tls)
That or wade through the tug log to see if the tls connection closed before we tried to send the UPDATE. If that happened, that'll explain the issue.
-
I did make Send options keepalives is set to "Always" but ill change it back to "Only behind a NAT" .
I tried to get the set to TCP but was having issues with it registering properly but it seems like its something I need to look at again.
Which specific Tug log should I be looking at, there are a few that begin with Tug.
I attached a couple of call flows , its still left to right - Internet - MBG - MiVB . I'm not sure if they help any.. Thanks again..
-
the one called "tug/tug.log" should, as it's the latest before rolling over and getting compressed.
as for the tcpdump capture, it isn't sip flows that you want to look at but, rather, the connection to the set itself.. does it stay up during the call? It needs to or stuff just won't work.