3CX Wrong Behavior on SDP Media Attribute a=sendonly

[Gioal]

Hi.

Symptom:
Extension make a call using sip trunk and hear 3CX MOH.

Problem:
Extension make a call via sip trunk but the phone number is wrong, so provider send back a message that says the number is wrong, but 3CX plays MOH to extension instead of the provider message.

Evidence:
Provider send "183 Session Progress" with "SDP Header" with "Media Attribute a=sendonly". That means provider will not accept receiving RTP media, it will only send RTP media (the wrong number advise message). 3CX doens't understand (or doesn't accept) this and play MOH instead of receiving RTP and connect to extension.

Who is wrong?
The "RFC3264 - An Offer/Answer Model with the Session Description Protocol (SDP)" says that

"If the offerer wishes to only send media on a stream to its peer, it
MUST mark the stream as sendonly with the "a=sendonly" attribute."

Source:
https://datatracker.ietf.org/doc/html/rfc3264#section-5.1

Sip provider response with Media Attribute a=sendonly


It would be great if 3CX explain this. But please, only explain why this is the behavior if RFC says another thing.

 

[NickD_3CX]

The Outbound Rule that was used by this extension to make the call, would it happen to have more than 1 Route configured?

 

[Gioal]

No. Only one route.

 

[NickD_3CX]

What version of 3CX are you currently running?
Switch on Verbose, start a capture, replicate it again and then generate a Support Info, then upload it to a file sharing service (e.g. Dropbox) and send me the DL link in a PM.

I can have a look to try and solve the mystery.

What you are saying does sound strange indeed.

 

[Gioal]

3CX Version 16.0.9

 

[NickD_3CX]

I checked the files and to be honest I should have remembered this, when we receive a "sendonly" in the SDP, we take that as the signal to put the call on hold. IP Phones use the same methodology.

As this is quite common, that's why most providers even when they send a 183 use the "sendrecv".

This has been like this for as long as I can remember and it is not planned to change soon, I have made a note though in our system so that if we do decide to action this at some point, I will try and update this thread.

 

[Gioal]

Ok. Thanks.

But you understand that 3CX behavior is not aligned with RFC?

 

[NickD_3CX]

Ok. Thanks.

But you understand that 3CX behavior is not aligned with RFC?

On this part, yes.

In our defense, most IP Phones out of the box use this way to put calls on hold, blindly following the RFC would result that any IP Phone that puts on a call on hold would result in the other side hearing dead air.
While the change is feasible, we'd have to also check all supported IP Phones if they can use something else like 'inactive'. Also, while our supported providers use 'sendrecv' in these cases, it cannot take high priority.