New features in the AudioBridge plugin

[Lorenzo Miniero]

Hi all,

we're experimenting with new features in the AudioBridge plugin:

1. spatial audio support, to position participants spatially using stereo streams;
2. support for plain RTP participants (e.g., for external audio and/or legacy users like SIP).

You can find them implemented (separately) in the two pull requests below:

https://github.com/meetecho/janus-gateway/pull/2446

https://github.com/meetecho/janus-gateway/pull/2464

If either interests you, please do test them and provide feedback, so that we can iron out any last remaining issue and merge them in master soon.

Thanks,

Lorenzo

[Mirko Brankovic]

very nice features, great work :)

--
You received this message because you are subscribed to the Google Groups "meetecho-janus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/meetecho-janus/f468b216-5b6c-423f-b95d-2b8bb73e4a4cn%40googlegroups.com.

--

Regards,

Mirko

[Hemrajsinh Gharia]

Great work @Lorenzo Miniero 

Re: plain RTP support, so unlike rtp_forward, I assume this is associated with the session. And AudioBridge will stop sending RTP when the associated session is destroyed. Correct?

Thanks,

Hemrajsinh Gharia

https://ghariaonline.wordpress.com/

   

To view this discussion on the web visit https://groups.google.com/d/msgid/meetecho-janus/CAND18T1_8J%3D8woXA-E%2BxLSznFQZgOCg2U6XCjqpBWtQP-EaJOA%40mail.gmail.com.

[Lorenzo Miniero]

Re: plain RTP support, so unlike rtp_forward, I assume this is associated with the session. And AudioBridge will stop sending RTP when the associated session is destroyed. Correct?

Yes. Unlike rtp_forward, though, this is bidirectional, and will be visible as an additional participant in the room.

L. 

[Lorenzo Miniero]

No one cares about either feature? Haven't received any feedback on the PRs so far.

L.

[moul...@gmail.com]

Hello @Lorenzo Miniero ,

We are working on new features and will update you definitely. Thank you.

Best Regards,

Chandramouli.

[august black]

Hi, I'm new to Janus.

I just started playing with it a few days again, got up and running in no time, but was disappointed to discover the audiobridge only did mono.

That is until I discovered this thread!   I was very glad to see work in progress on this.  I'd say stereo is a must-have feature.

all the best -august.

[Pallab Gain]

Hi !
I have been trying Plain RTP participant PR but failed to test it and was wondering if someone can point me where I am doing wrong.

In my local setup, I am following mentioned step(s)

1. Use audio room plugin demo to join a participant in room 1234

2. Using a WS client to join the same 1234 room to configure a Plain RTP participant that does the followings

   • Create session
   • Attach handler
   • Join room using the following payload ( only mentioning this one since it is different than other payloads )
   
   
   { 'body': { 'display': 'rtp-listener', 'request': 'join', 'room': 1234, 'rtp': { 'ip': '172.17.0.2', 'port': 5002, 'payload_type': 111, 'sampling_rate': 48000, 'audiolevel_ext': 1, 'fec': true }, }, 'handle_id': handlerId, 'janus': 'message', 'session_id': sessionId, 'transaction': uuid() }

   I am getting this response against successful join room request

   { "janus": "event", "session_id": 3827255295780906, "transaction": "ae6c569a-94a0-427d-9ac7-48d179ac07e2", "sender": 5890147408366167, "plugindata": { "plugin": "janus.plugin.audiobridge", "data": { "audiobridge": "joined", "room": 1234, "id": 182533113635298, "participants": [ { "id": 2606423716259588, "display": "123123", "setup": true, "muted": false, "talking": false } ], "rtp": { "ip": "172.17.0.2", "port": 10026 } } } }
   

3. Now, I start streaming the plugin demo and try to listen to the stream from the configured stream list that is listening to port 5002

Unfortunately, I hear to voice. To verify,

      1. I have checked chrome webrtc internals and there is no received packets.

      2. Used Wireshark and there is no RTP stream on port 5002

But, if I just simply setup rtp forward to same streaming plugin destination, then there are received audio packets ( Wireshark and webrtc internals ) and I also hear voices.

I am under the impression that I am missing something quite obvious with the Plain RTC participant feature ( since it is already mentioned working in the PR ). So, I was wondering if you can shed some light here! :D

Regards,

- Pallab

[Mirko Brankovic]

As you can see from response you got from janus, audiobridge used 10026 port, now I have no idea why 5002 was not accepted, maybe it is taking from UDP-port range specified in media config part only

--

You received this message because you are subscribed to the Google Groups "meetecho-janus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/meetecho-janus/ac10d238-6d4b-4e64-aa38-9e1daecefdbcn%40googlegroups.com.

--

Regards,

Mirko

[Pallab Gain]

That was a good hunch. Thanks for pointing it out and my apologies that you had to guess my audiobridge plugin config ( Yes, I am using default port range 10000-60000 ). I just changed the port based on your feedback and tried with 10900 instead of 5002. 

Unfortunately, there is still no luck in my test. :(

[Mirko Brankovic]

oh sorry i misunderstood feature, 10026 is port where Janus will expect audio from your plain rtp client

To view this discussion on the web visit https://groups.google.com/d/msgid/meetecho-janus/215af1c0-4abd-4175-aff6-d8b9fd2e61afn%40googlegroups.com.

--

Regards,

Mirko

[Pallab Gain]

I think I have figured out the problem with my particular test setup. In my test, 

     janus_audiobridge_setup_media method  is never called for a plaint RTP partipant. I might be wrong, but it is probably because the implementation expects some RTP packets to come in order to first set up media for a plain RTP participant ( PR reference )

Also, it is probably not intended for the use case I was trying ( i.e. My plain RTP participant is a recv only RTP participant. I meant, just like an old RTP sink that can be achieved simply by RTP forwarding but I wanted it to be bound with a Janus session )

I was able to make it work by removing the first packet requirement condition ( Basically, calling janus_audiobridge_setup_media after the Plain RTP participant thread is successfully initialized )

I was wondering if there is any plan to support recv only Plain RTP participants with the same PR? Or, if it is already possible in this feature through different techniques?

Thank you again for bringing yet another powerful feature to Janus. 🍻

Regards,

Pallab

[Lorenzo Miniero]

If you need recvonly participants, this PR makes little sense: just use RTP forwarders for that, which the AudioBridge supported already. This PR is meant for active RTP-only participants, and so expects incoming traffic from them: until that happens, I think we don't send any packet.

Lorenzo

[ime...@gmail.com]

Nice! Great job, Lorenzo :)

I'm especially interested in the second feature. Any idea if it can be used in combination with the SIP plugin?

For example, orchestrating app can register to the SIP plugin so when an INVITE is received, the call will join an audiobridge room. Currently, the only issue I can see here, Janus changes the original SDP in the INVITE so there are no original IP and port for plain RTP. Maybe we can add an option to the SIP plugin to behave like a "proxy" in some cases. In that way, we will avoid handling the media in the SIP plugin so Janus will just proxy the original INVITE to the orchestrating app. Also, all other SIP requests that include SDP should not be changed.

Let me know what do you think.

[Амнон Исраэли]

Yes, really awesome!

I still cannot check it due to a catastrophic lack of time.. :(

But it's really help in our translation system

понедельник, 8 февраля 2021 г. в 21:00:29 UTC+2, ime...@gmail.com: