AudioBridge, RTP Join, SIP Scenarios

General
1

Hi,

Intro/Context:
We are using AudioBridge to build an audio conferencing solution, including SIP and WebRTC connections.
Our objective is to support both Dial-In and Dial-Out from SIP, so we are extensively using the RTP join feature.

Requirement:
We want to direct the mobile operator’s unavailability message saying “The person you are trying to reach is currently unavailable…” to the AudioBridge room, which the RTP is negotiated within SIP 18x SDP. (SIP Ringing or SIP Session Progess)

The challenge with AudioBridge:
For a happy path outbound call,we can send an INVITE without an SDP, get the SDP from SIP OK, send it to the Janus RTP join API, and finally answer SIP/OK with an ACK containing Janus SDP. (it is working)

But in the case of SIP 18x with SDP, SIP messaging requires that we send an INVITE with SDP (SDP of Janus) to be able to receive the RTP

Troubleshooting actions:
We have sent a dummy SDP port to Janus to get Janus SDP, and we have initiated a SIP INVITE with Janus SDP. Janus server have received RTPs on the correct port, but unfortunately, AudioBridge discards RTPs since the RTP source port is different from the one provided by the JoinRTP API.

So does anybody have a suggestion?

2

I don’t think there’s a solution, other than avoiding that offerless INVITE, which the AudioBridge plugin obviously knows nothing about as (on purpose) we kept the SIP semantics a thousand miles away from it. The AudioBridge expects a rigid flow for establishing a plain RTP participant, and as you noticed does indeed do a connect on the RTP socket to ensure it’s the negotiated addresses that will talk to each other.

3

Will it be correct according to the audiobrigde design the fallowing proposals

1- Have a AudioBridge RTP Join API with two steps:
API1: An RTPJoin API to request an SDP from Janus AudioBridge without providing a SIP SDP.
API2: A second RTPJoin API to send SIP SDP to Janus with the previously provided participantId.

2- Have an Api something like change the source of the RTP

İf you can advise on a correct way we may consider making the contribution on audiobridge