RTP before OK

[ddstech]

On prem 3CX v18.

We have a persisstant issue with inbound calls which presents as 1 way audio. We do not use IVR / Digital receptionist so all calls are directed to a group, all members of group are local extensions running 3CX client. In simple terms, caller rings, we answer and hear them but they can't hear us. 30 seconds later we've all hung up and they try again, usually with success. This probably effects 30% of inbound calls. Outbound calls are fine.

Majority of our inbound calls are from regular callers and it's obvious that some callers never have an issue and some are almost guranteed to fail first attempt. The callers with issues are a mix of mobile and landline users.

Pcap shows the same (interesting?) results for both failed and sucessful calls which has been confirmed with VoiceFlex SIP provider.
"PBX is sending early media without sending 183 first".

So flow from pbx goes something like this.. (Invite) - 100 Trying -> 180 ringing -> RTP-> 200 OK

It would seem that the above flow is accepted or handled by some inbound provers but not others.

Indeed call recording and captures show that audio is making it out of the PBX, just earlier than caller is expecting it.

I have toggled Earlier Media on and off, no difference and I've never seen a 183 in any pcap performed on inbound calls.

 

[bitn2]

Did the firewallcheck pass?

 

[ddstech]

Firewall Check passes if I amend firewall rules to allow "any" source for Inbound rules;
9000-60000 UDP
5060 TCP/UDP
Otherwise these are restricted to the SIP providers documented range as source

 

[SweetAction]

Firewall Check passes if I amend firewall rules to allow "any" source for Inbound rules;
9000-60000 UDP
5060 TCP/UDP
Otherwise these are restricted to the SIP providers documented range as source

The first one - 9000-60000 (which unless your PBX license size in in the hundreds should be 9000-10999) needs to be open to all, not just your trunk, as some providers do direct media (i.e. the sender sends RTP directly to the PBX). Flowroute is an example of this: https://support.flowroute.com/136672-What-is-Flowroutes-Direct-Media-Delivery but many others do as well.

This would explain why only some calls are affected too. I bet if you check the provider on them it will be a common set/group.

 

[AWS2P]

here the FW doc for ports to be opened
https://www.3cx.com/docs/manual/firewall-router-configuration/

 

[bitn2]

The first one - 9000-60000 (which unless your PBX license size in in the hundreds should be 9000-10999) needs to be open to all, not just your trunk, as some providers do direct media (i.e. the sender sends RTP directly to the PBX). Flowroute is an example of this: https://support.flowroute.com/136672-What-is-Flowroutes-Direct-Media-Delivery but many others do as well.

This would explain why only some calls are affected too. I bet if you check the provider on them it will be a common set/group.

That is your problem, you can't restrict rtp ports to your provider.

 

[ddstech]

So I believe I followed https://www.3cx.com/docs/manual/firewall-router-configuration/ which states the ports in question are for comms with VoIP provider (VoiceFlex) and restricted as such.

The reason for extended UDP range is best described in https://www.3cx.com/community/threads/firewall-ports-differ-between-3cx-and-voiceflex-trunk.85380/ . It also goes on to describe the Firewall Test fail scenario and reasoning.

I appreciate that the calling parties will have some commonality in either the capabilities / compatibility or way the call is generated Odd that the same callers ever manage a sucessful call but looking at packet captures traffic flow seems the same from our side regardless of if the caller does or doesn't hear our audio stream.

Probably my lack of understanding but what doesn't follow logic to me at this stage is why inbound ports would affect the inbound caller not receiving the outbound RTP stream that has been seen in packet captures at both pbx and VoiceFlex end. This is where the RTP before 200 OK and EarlyMedia has been brought in to question.

So questions:
In practice the RTP ports needs opening up to all sources inbound?
Can 5060 UDP 5060-5061 TCP remain restricted to VoIP provider?
With port restrictions lifted we you expect my pcap to start showing flow in the "correct" order?

 

[bitn2]

In practice the RTP ports needs opening up to all sources inbound?

No, outbound. Portforwarding can only go to one ip address. 5060 can be restricted to your voip provider, but not rtp.

 

[ddstech]

So firewalls I do understand...

We have no outbound retrictions in place, just a rule to ensure static port is used.

All port forward rules are destined for our PBX and I've run tests with source allowed as "Any" for both 5060 and RTP rather then restricting to VoIP provider.

RTP still shows as flowing before 200 OK.

Just need some clarity on the inbound firewall.
Are you saying inbound allow VoIP provider IP's only for 5060 but ANY for the RTP?

Happy to test in that scenario but the RTP before OK still seems odd?

 

[bitn2]

Are you saying inbound allow VoIP provider IP's only for 5060 but ANY for the RTP?

correct

 

[SweetAction]

The reason for extended UDP range is best described in https://www.3cx.com/community/threads/firewall-ports-differ-between-3cx-and-voiceflex-trunk.85380/ . It also goes on to describe the Firewall Test fail scenario and reasoning.

I read through that thread and I think you are misunderstanding it

In this post, https://www.3cx.com/community/threa...een-3cx-and-voiceflex-trunk.85380/post-401351, a 3CX employee stated "They must be referring to their own source ports meaning this is actually outbound traffic for you and incoming for them. The ports require by 3CX are the ones @Saqqara linked to here."

In this post, https://www.3cx.com/community/threa...een-3cx-and-voiceflex-trunk.85380/post-401843, cobaltit (who is very knowledgeable over the years) echo'd what I stated, namely "Some providers stay in the audio path so the RTP would come from their IP range. Others don't stay in the audio path which means the RTP wouldn't be coming from their IP ranges necessarily."

The firewall test isn't the "end all, be all". It's a really good tool for troubleshooting, but you run it on any of my systems you'll see they all fail but everything works. However, when things are broken, that's when you'll want to make sure the firewall test passes and the issue can be replicated.

You have a really easy way to test this - remove your source restrictions on your UDP range (which you can lower down significantly, but won't hurt to keep it as is) and see if the issue continues - my money is that it will be fixed. But if not, remove your restrictions from the SIP port and pass the firewall checker, then ensure the issue continues - this will rule out your firewall configuration. You may need to cycle the firewall and/or 3CX after the changes depending on how your network is setup and how states are treated - or maybe clear all open states - I don't know what you have and it's configuration - so keep that in mind.

 

[ddstech]

OK Thank you for repsonses.

I will run with restricion on 5060 only.
Appreciate the comment regarding UDP range shouldn't do any harm so will consider lowering once things settle so will monitor.

Interesting nobody has commented on the RTP before 200 ok yet which is the route VoiceFlex sent me down due to the pcap results?

 

[SweetAction]

Interesting nobody has commented on the RTP before 200 ok yet which is the route VoiceFlex sent me down due to the pcap results?

The reason I ignored this is because you said it happens on both calls that work and don't work.

Pcap shows the same (interesting?) results for both failed and sucessful calls which has been confirmed with VoiceFlex SIP provider.
"PBX is sending early media without sending 183 first".

I focused on the solution to the issue, not something which is potentially weird.

 

[ddstech]

OK so update, still had issues with RTP ports open to any source and 5060 locked down to provider so have left all inbound rules to allow any source.
Firewall test passes/

Still same issue as described initially. In bound caller can not hear the outbound stream. Call flow attached and I can confirm the RTP Streams do contain audio. (WAN - PBX - 3CX Client shown below).

 

[SweetAction]

Do you have support reinvites enabled on the trunk?

 

[ddstech]

No, "Supports Re-Invite" = unchecked

 

[SweetAction]

If you check it, does the issue disappear? Only on the trunk, not the extension.

 

[ddstech]

So firewall still open for any source, re-invites enabled on SIP trunk options but still failed audio. The attachments show the same inbound caller on failed attempt (220524.jpg) followed by a succesful attempt (250524_2.jpg) 30seconds later. Same caller (from a mobile) and same extension answers. RTP streams shows all show audio is present.

May be a clue or I'm getting side tracked but what still throws me is that given this is an inbound call surley the first RTP stream to appear would be from Client (on the right most) to either PBX or Caller.
How can the RTP flow from port 9166 on PBX to 38764 on WAN and contain audio when it's 5 lines later when the same audio shows as flowing from Client port 42608 to PBX on 8064.
2nd call I notice order of events is slightly different and the PBX -> RTP streams are not split with the 200 OK's and ACK

 

[ddstech]

So issue still persists
Firewall still open and passes test
Re-invites checked.

Seem to be at a dead end apart from VoIP provider telling me RTP is occuring before 200 OK

3CX subscription is due for renewal in a couple of weeks so may be time for a change!

 

[bitn2]

Is it an supported provider? There must be still some network issues. I didnt have such issues at all, with none of my customers.