expected SBC network traffic path for conversation on two local IP phones?

[ClarksvilleTN]

We have local Yealink 54W IP phones on Voice VLAN with 3CX supported firmware and 3CX standard yealink model template.
We have onsite linux 3CX SBC for the Yealink IP phones.
Our 3CX instance is hosted in the cloud by one of the certified providers.

Question:
When a conversation (RTP or SRTP) traffic occurs between two local IP phones connected to the same SBC.
I thought the RTP traffic would go from phone 1->SBC->phone 2.
But what our packet capture shows is the traffic is phone 1->SBC->hosted 3CX->SBC->phone 2.
Is the traffic flow that I'm seeing what is expected? Or have we misconfigured something?

I'm asking because we are getting a lot of extra latency in our conversations between local phones because all of the traffic is going out to hosted 3CX and back.

 

[paulodagraca]

Hello,

Yes the expected route for the voice RTP sream will be from phone to phone.
However this is NOT always the case.

Example, you turn on the call recording for one or both phones, then the audio will need to go to the 3CX and back.
Also there is a setting on Extension page options, that let you tick the PBX Deliver Audio option, this will also cause the audio to goto the 3CX.

Paulo

 

[ClarksvilleTN]

Thanks for the informed reply! What you say makes complete sense.
However, in our testing/troubleshooting we have no call recording enabled and do not have the "PBX Delivers Audio" checked.
Yet our SBC s are still sending the traffic out to the cloud 3CX... for some unknown reason.
Should SRTP option choice make a difference?

 

[Saky]

Is the SBC on the same VLAN as the phones too?

 

[JohnS_3CX]

In a nutshell, for two phones on the same LAN as their SBC:

RTP Mode: Will stay local between phones, except if there are recordings or PBX Delivers Audio enabled.

SRTP Mode: The audio will go through the PBX always.

 

[ClarksvilleTN]

Is the SBC on the same VLAN as the phones too?

yes

 

[ClarksvilleTN]

In a nutshell, for two phones on the same LAN as their SBC:

RTP Mode: Will stay local between phones, except if there are recordings or PBX Delivers Audio enabled.

SRTP Mode: The audio will go through the PBX always.

Great info to know!
Our packet capture at the SBC was showing RTP from phone to SBC, then streamed SRTP from SBC to cloud hosted 3CX PBX. We think that because our 3CX hosting provider is having some unresolved performance issues is why we are having poor conversation quality between local IP phones.
The knowledge you shared will help in our further troubleshooting. Thanks!

 

[ClarksvilleTN]

So we learned that our 3CX hosting provider was having performance problems that were creating poor internal IP phone conversation quality (among other issues.) The 3CX hosting provider has thankfully fixed the issue and now call quality for internal and external calls are good. This learning from this troubleshooting led us to an additional decision.

Since the 3CX extension level setting of SRTP=enabled, is Not setting the Yealink IP phones to SRTP enabled, all of our internal extension calling is RTP on the local LAN anyway. What the SRTP=enabled does is cause the SBC to send the call traffic out and back to 3CX in the cloud. The SBC to 3CX PBX is SRTP, but there is really no benefit in the longer network traffic path. So we now set SRTP=disabled for our extensions. Now the internal IP phone call RTP conversation traffic is all local between IP phones and SBC. Even with SRTP=disabled, we verified that any external calls are still using SRTP between SBC and 3CX PBX. We also verified that 3CX web browser phone is still using encrypted SRTP to 3CX.

It seems that if we are satisfied with local LAN (non-encrypted) RTP, then there is no reason for setting 3CX extensions to SRTP=enabled. I think if we wanted local LAN (encrypted) SRTP, that we would have to apply a custom template change to our Yealink IP phones anyway.

Any thoughts of agreement or disagreement with this thought logic?

 

[JohnS_3CX]

The path between SBC and 3CX is encrypted, so yes if that is sufficient for your needs then you do not need to enable SRTP.

If you want local encryption too, you will have to set SRTP to "Enforced" and also manually set it on the Yealinks to "Compulsory" (custom template not strictly necessary).

The trade-off is that your traffic will always go via the PBX, and also in some rare scenarios your calls might not get established or get dropped if the Yealinks happen to have a call with an endpoint that does not have SRTP. That's what they mean by compulsory.

 

[ClarksvilleTN]

The path between SBC and 3CX is encrypted, so yes if that is sufficient for your needs then you do not need to enable SRTP.

If you want local encryption too, you will have to set SRTP to "Enforced" and also manually set it on the Yealinks to "Compulsory" (custom template not strictly necessary).

The trade-off is that your traffic will always go via the PBX, and also in some rare scenarios your calls might not get established or get dropped if the Yealinks happen to have a call with an endpoint that does not have SRTP. That's what they mean by compulsory.

This is GREAT insight. Thank you for sharing that knowledge! It helps us for the fine tuning of our new 3CX implementation.