Raspberry Pi SBC & v14 Shared Parking Music on Hold Problem

[uptime1]

Environment: 3CX Cloud v14 SP2, Raspberry Pi SBC 1.0.0.44201, Yealink T48G tried both firmware 35.73.0.50 and 35.80.0.70

I'm seeing odd behavior with Shared Parking between phones behind a RPi SBC.

When a call is made phone to phone (both phones are on the same LAN behind the SBC), when either phone puts the call into Shared Parking (using an assigned BLF), Music On Hold is not played to the other phone and often times, after the call is picked up from Shared Parking, only one-way audio is heard.

Additionally, when the call is picked up from Shared Parking, the direct phone to phone RTP network traffic communication path is lost. Instead, both phones begin communicating with the server, which is unfortunate because that's bandwidth intensive and abandons the convenient efficiency intended by using the SBC.

This problem does not appear to occur on voip provider calls coming into the server then phone extension. IOW, a typical incoming call.

This problem is easily duplicated on other 3CX frowned upon phones, so it's not specific to Yealink, but rather a RPi SBC programming problem.

3CX will you duplicate my environment in your lab and packet sniff the communication to see where it's falling down, please?

Thanks!

 

[bardissi]

Remember the PI is only designed to work with very small installs 7 phones or less.. do you fit in that range?

 

[leejor]

Does the same thing happen if you don't use the BLF method of parking the call?

Have you tried (as a comparison test, not a permanent solution), using the windows version of the 3CX SBC?

It very well might be a Yealink issue, have you tried any other make of sets?

I'm wondering if it could be a network/port issue (are you using the SBC with the tunnel ?), or perhaps , the functionality of shared parking between two extensions was considered rare (one extension calling another with no outside call being involved) that this scenario was not tested thoroughly.

When the call is first put on hold and no music is heard, I have to assume that the call is "sent" to the PBX to be connected to the music, and that is where the problem begins. The fact that , it is intermittent, is puzzling. It makes it much harder to troubleshoot than an issue that can be duplicated every try.

You might have to resort to using Wireshark to pinpoint the problem, particularly comparing a call that reaches music initially, and one that doesn't.

 

[uptime1]

Thanks for the replies! ;-)

The problem is occurring with just two phones behind the RPi SBC. I tested other phones, they exhibit the exact same problem.

The problem did not occur using 3CX v12.5 and a previous version of the RPi SBC app.

I spent an entire day troubleshooting and comparing various iterations of phones, firmwares and configurations. I've carried the ball more than far enough. It's entirely appropriate for 3CX to take over from here.

 

[NickD_3CX]

Can you check if the "Supports Re-Invte" and "Supports 'Replaces' header" options are enabled for those 2 extensions that are behind the SBC?
You can find those options under the Extension Settings for each extension in the "Other" tab.

 

[uptime1]

Hi Nick, yes, the two extensions (and all other extensions, by default) have "Supports Re-Invte" and "Supports 'Replaces' enabled.

 

[uptime1]

Nick, if you tell me how to access previous RPi SBC app versions, I'll try them.

In case it helps, I want to mention this previous RPi SBC issue:
http://www.3cx.com/forums/post165056.html

Thanks!

 

[NickD_3CX]

I just had a chat with some of the people in the Testing Department and apparently working on a few fixes related to how RTP streams are handled for calls through the SBC for SP3.
I don't have an ETA for SP3 but could I suggest to wait until SP3 is out and review this?

 

[NickD_3CX]

* Update *

A few days ago a new version of the SBC was released with a few fixes. Try upgrading the SBC and see if you still have the problem.
Of course any feedback would be more than welcome.