Open keremcadirci opened 4 months ago
To be honest, I don't like this approach, which seems wasteful. It creates a socket already knowing it will be destroyed shortly thereafter. I'd rather see a possible alternative to RTP participants creation, where the plugin is asked to provide a port first, and the application will then provide their own later on (e.g., via a configure
). This would map better to an inverted negotiation pattern (where the plugin "offers" and the application "answers"). We have both approaches already on the WebRTC side, for instance, so you can see how that's done for WebRTC to possibly reuse the same methods and just add the required attributes there.
Do you suggest something like generate-offer
with join
request ?
In that case which of two join
request would you prefer (or a 3rd suggestion):
generate-rtp-offer
attribute
{
"request" : "join",
"room" : <numeric ID of the room to join>,
[..]
"generate-rtp-offer: <true|false, whether audioroom reserve a local port to receive rtp. configure request should be later usedd to setup the PeerConnection\>
}
generate-offer
into rtp
object
{
"request" : "join",
"room" : <numeric ID of the room to join>,
[..]
"rtp" : {
"generate-offer: <true|false, whether audioroom reserve a local port to receive rtp. configure request should be later usedd to setup the PeerConnection. If true all other rtp properties are discarded\>,
[..] <other properties are discarded\>
}
}
I think the second one is better, since it adds the property as part of the already existing rtp
container. For consistency it should use a generate_offer
, though (notice the underscore), since that's how the property is called for WebRTC usage.
The fallowing rtp
.generate_offer
is added
{
"request" : "join",
"room" : <numeric ID of the room to join>,
[..]
"rtp" : {
"generate_offer: <true|false, whether audioroom reserve a local port to receive rtp. configure request should be later usedd to setup the PeerConnection. If true all other rtp properties are discarded\>,
[..] <other properties are discarded\>
}
}
@lminiero My previous remarks about limitations and tests remains the same
That's a LOT of new code... I'm not sure I'm comfortable with that many changes in critical parts of the plugin. I'll need some time to review this.
This PR is intended to address the topic discussed in https://janus.discourse.group/t/audiobridge-rtp-join-sip-scenarios/1049/3
This PR enhance slightly SIP interoperability provided by the plain RTP join feature of AudioBridge, such as in the case of an 18x message with SDP. Specifically, during an outbound SIP call, there is currently no way to direct RTP issued from a SIP 18x Ringing or Session Progress (e.g., ringback tone provided by RTP or a custom message sent by the operator during ringing), into the AudioBridge room.
Solution Proposal:
rtp
object in theconfigure
apijoin
requestjoin
request, then reconnect/rebind the same local RTP port with the the new remote RTP provided byconfigure
request.rtp
object inconfigure
request only if the participant has previously joined with plain rtp.configure
requestI believe this approach is backward compatible.
How this enhancement improve SIP interoperability? How will SIP/janus flow will be?
configure
request to janus with 18x SDP. Thus Audio room participants will hear rinback tone or ring message into roomconfigure
request to janus with SIP OK SDP or (2) make a RE-Invite without SDP and rejoin to janus ....Implementation & Tests
We have well tested with real word use cases:
Tests successfully made:
rtp
object is not present everything works as expected.netstat
that the existing socket is correctly changed afterconfigure
request. We have seen that both way RTP sessions are OK and both way audio communication is well established. the socket is closed after participant left or after session close.confiure
rtp
requests on a single session works fineallowRtpParticipants
isfalse
on room, (2)join
event does not containrtp
Not Tested:
payload_type
changes onconfigure
is not tested