one-way audio: 3CX not progress audio packets

[Luis C]

Hello,

3CX is receiving RTP traffic from Trunk SIP but it is not progressing it to the registered device.

The scenario is the following:

Yeahlink phone -> 3CX -> SBC -> TDM
(yeahlink, 3CX and SBC are in the same network)

we would like to not anchor the media in 3CX so uncheck "PBX Delivers Audio" at trunk level. But it does not work, 3CX puts its IP in SDP messages so media is anchor on 3CX.

The problem is that RTP packets from SBC SIP Trunk are not progress to Yeahlink.
No matter if it is a call made or received by Yeahlink, RTP from SIP Trunk is not progressed.
See following wireshark captures taken from PBX host:


RTP flow from YeahLink:
- Yeahlink -> 3CX (line grey)
- 3CX -> SIPTrunk (line brown). 3CX is progressing the RTP properly
RTP flow from SIP Trunk:
- SIPTrunk->3CX (line Green). It is posible to listen to the audio and it is OK.
- 3CX-> terminal (línea blue), as you can see, is a flat line. RTP received is not progressed to Yeahlink by 3CX.

Note connectivity is OK:
- calls between Yeahlinks connected to 3CX works properly
- If TDM endpoint is replaced by another SIPTrunk (Yeahlink phone -> 3CX -> SBC -> SIP Trunk -> softphone), 3CX progresses audio properly.

Thus, here are my quesions:
- is it posible to not anchor the audio in 3CX (how Works "PBX Delivers Audio")?
- which process/logs manage media in 3CX?(where can I find if 3CX is managing the media?)
- is the following SIP signalling supported by 3CX?(caller is answering 183 SDP +180 +200 OK SDP)
could it be affecting the media management in 3CX?


Regards,
Thanks in advanced,
Luis C

 

[lneblett]

It would probably be better to simply post the capture so we can actually see the messaging rather than the results. It could be that the phones are directing the media rather than 3CX and as a result the RTP stream is not seen. The phone could be telling the SBC to send the RTP stream back to the phone rather than thru 3CX. You should do a capture at both 3CX and the phone and see if there is an something in the SDP section of the messaging that explains how the streams are being requested.

In the extension settings, as well as the trunk settings of 3CX, PBX delivers audio is used to prevent the endpoints from negotiating RTP streams directly between one another. In an ideal scenario, allowing the extensions to manage the RTP between extension to extension calls lessens the load on the PBX. However, you may want to enable PBX delivers audio and then disable the reinvites and replaces on the trunk and see if that helps.

As far as the messaging goes, it is not always up to 3CX to manage or determine how the provider responds. In your graph, the 183 & 180 are from the SBC which 3CX does not control. The 200OK/SDP is also from the SBC and may be the message of interest with regard to the RTP. Hard to say without being able to actually see the capture, but by looking at a capture at both 3CX and the phone, you will probably get to the bottom of it. If one can also be taken at the SBC, even better as you will have data from all 3 devices that form the path.

 

[Luis C]

Hi, thanks for your answer. I'm adding some comments:

[It could be that the phones are directing the media rather than 3CX and as a result the RTP stream is not seen]
No, Yeahlink sends media to 3CX and also SBC sends media to 3CX.

[In the extension settings, as well as the trunk settings of 3CX, PBX delivers audio..]
It is not set up, that is, PBX delivers audio is uncheck at Extension level. It is also uncheck at Trunk level. However, 3CX put its own IP in SDP... How can we do that 3CX keeps out of media path?

[If one can also be taken at the SBC, even better as you will have data from all 3 devices that form the path.]
we've already done, and seen the behaviour I explained: one RTP flow is OK but the other is not progressed by 3CX (that is, SBC sends it to 3CX but it does not reach the Yeahlink The pcap taken at Windows Server that hosts 3CX shows RTP is received from SBC).
Maybe RTP is managed by Windows Server but it does not by the application (3CX)... but I do not know how can I check it. is there any media logs in 3CX?