3300 with Direct SIP trunk - RTP connection issues one way

[Rixy]

Hi all,

Hoping I can get a few pointers with an intermittent issue I've been experiencing lately. Sorry if this is not in the right sub forum, I was toying with putting it in the SIP forum but went with the safe bet. 

We currently have a direct SIP trunk configured on our controller, with no MBG at any stage in the path. This has been working for many years with only provider issues arising. However, the last few months have seen an increase in issues with RTP not working for inbound audio once the call connects. However, if I place the call on hold and resume, forcing a new rtp stream, the audio is restored.

What's weird is that I get ring back from the provider when the call is progressing, but as soon as it connects with the far end, the inbound audio is silent.

Running on MCD 7.1  (13.1.0.33). This happens randomly but is slowly getting more and more frequent. Our inbound comes over ISDN (T1 for our non euro friends)

Anyone have any idea's? I thinking network possibly, but I would think this would affect every call if it was.

Cheers

[matthew]

I tend to suspect firewalls in cases like these. Your first step should be to capture the session with Wireshark. Does the RTP stream come from a different IP than the SIP proxy at the provider end?

[Rixy]

Cheers matthew,

The provider only advertises one IP for media and signalling. and looking at captures from both their end and ours, that's staying true.

What's really weird is that you can kind of hear a little bit of RTP and it's almost like it shuts off. Then, hold and resume sorts it out, but re-negotiates different RTP ports.

[x-man]

Make doubly sure your firewall has all the ports open it needs and there is no SIP ALG enabled (especially if you have recently upgraded it....)

[Rixy]

cheers x man. I have checked the firewall and this isn't enabled. On the flipside, if it was, I would expect every call to fail, not just the intermittent ones. all necessary ports are open so I don't believe this is an upperbound port issue. Especially after finding the following.

Hopefully, here is a bit of a helper for us. Some of our phones are recorded using a Mitel SRC server. I can replicate the issue (with perseverance) and can successfully hear both legs of audio on the recording server. Which would bring the issue to within the LAN. I've tried to get a capture from between my phone and the SRC, but I believe the encryption is getting in the way, as I get white noise on both legs.

I feel it getting closer!!!

[JasonTL]

I have through the years had several issues just like this. Almost always a firewall issue as stated above. I tried setting up a virtual MBG for testing and didn't have any issues. I started quoting the MBG with every install and have better luck for sure.

J

[Rixy]

Cheers Jason,

I believe you are right. We don't install without an MBG anymore.

Cheers for all the replies.

[Dutch]

Hi Rixy,

Have you looked into the SDP options as well? You show a scenario where when you force a re-invite (hold/unhold etc) the RTP stream comes back.

The following options are to me usually a default concerning rtp. In the past we had the same issues on certain trunks. By using these options I was in some cases able to solve the audio issues.

Avoid Signaling Hold to the Peer - Yes
Force sending SDP in initial Invite message - Yes
Limit to one Offer/Answer per INVITE - Yes
NAT Keepalive - Yes
Prevent the Use of IP Address 0.0.0.0 in SDP Messages - Yes

And with re-invites the following option might have influence as well but thats from experience since providers I have made connections to don't usually like the Mitel to send inactive.
Suppress Use of SDP Inactive Media Streams - Yes

Let me know if this helps, but you might have probably set these already or have tried them and yes MBG makes everything a lot easier

Cheers

[Rixy]

Thanks Dutch.

I'm going to give them a go because most of the options you have mentioned I have set at default. The problem is that I can't seem to replicate the issue as easy as I did before. It seems to have "gone away" in the last month. which smells like the provider has possibly been fiddling during their maintenance windows.

I'm keeping your post close, as if I can get it to do it consistently with a test number again, I will look at editing the options.

thanks mate.