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

[dilkie]

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.

[cabarrushealth]

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

[dilkie]

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.

[cabarrushealth]

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..

[dilkie]

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.