Janus as media proxy for SIPREC

263 views
Skip to first unread message

Patty Watson

unread,
Oct 7, 2021, 9:04:38 AM10/7/21
to meetecho-janus
Hi,
I am investigating the use of Janus as a media proxy to forward WebRTC (from my media server) to a long term recorder via SIPREC and RTP. 

     RTP (LTR) <----- Janus <------ WebRTC (media server)

The WebRTC connection is using max-bundle so multiple streams are bundled together. In a simple 2 party audio call, the WebRTC bundle will contain 2 audio streams.

I tried the nosip plugin and found that only a single audio stream is supported. Otherwise, the nosip plugin worked very well for my use case. The WebRTC offer (from the media server) was converted to plain RTP SDP and used to negotiate the connection with the LTR (via SIP). The answer plain SDP answer from the LTR was used to negotiate the WebRTC connection with the media server. 

Media flowed fine (but only for the first stream in the bundle). On receiving a new WebRTC offer with a stream added for the second party in the call, the returned answer SDP marked this new stream as inactive in the bundle. Is it possible with the nosip plugin to renegotiate only the WebRTC side and add streams to flow to the single RTP port of the LTR?

If not, I am wondering if there is a better plugin that I should try. I looked at the videoroom plugin (specifically the rtp_forwarder attribute of the publisher) but I still need to negotiate the RTP port with the LTR before I can set up the rtp_forwarder. I'm not sure how to do that with the videoroom plugin. It's like I need a combination of the two plugins (nosip to produce an SDP for the LTR, and video room to handle the RTP forwarding).

I'm rather new to Janus so any advice would be appreciated.


Lorenzo Miniero

unread,
Oct 7, 2021, 11:46:09 AM10/7/21
to meetecho-janus
Il giorno giovedì 7 ottobre 2021 alle 15:04:38 UTC+2 patty....@motorolasolutions.com ha scritto:
Hi,
I am investigating the use of Janus as a media proxy to forward WebRTC (from my media server) to a long term recorder via SIPREC and RTP. 

     RTP (LTR) <----- Janus <------ WebRTC (media server)

The WebRTC connection is using max-bundle so multiple streams are bundled together. In a simple 2 party audio call, the WebRTC bundle will contain 2 audio streams.


That's how Janus works too. We bundle all media in a single PeerConnection.


I tried the nosip plugin and found that only a single audio stream is supported. Otherwise, the nosip plugin worked very well for my use case. The WebRTC offer (from the media server) was converted to plain RTP SDP and used to negotiate the connection with the LTR (via SIP). The answer plain SDP answer from the LTR was used to negotiate the WebRTC connection with the media server. 


The NoSIP plugin can definitely handle both audio and video in the same PeerConnection as part of the same bundle: that's what the demo does, and is actually the only way Janus will handle that. If only audio is getting through, maybe the media server is sending video on a separate port we ignore? What's this media server using?

L.

Patty Watson

unread,
Oct 7, 2021, 12:16:32 PM10/7/21
to meetecho-janus
Just to clarify, I am not trying to send both audio and video in the same PeerConnection. I am trying to send 2 audio streams that are bundled together. My media server is GStreamer based. Here is an example offer from my media server that has the 2 audio streams. The resulting answer from Janus has the second stream inactive.

Media Server Offer:
v=0
o=- 1681714812466801261 1 IN IP4 0.0.0.0
s=-
t=0 0
a=ice-options:trickle
a=group:BUNDLE audio0 audio1
m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=setup:actpass
a=ice-ufrag:d7e3iCBCbG7Qs91L/nxfLmMytBN4IJGh
a=ice-pwd:L67u+Mac7Cy2L5Jwc++YpfUgddGhQn73
a=rtcp-mux
a=rtcp-rsize
a=sendrecv
a=rtpmap:111 OPUS/48000/2
a=rtcp-fb:111 nack pli
a=fmtp:111 sprop-maxcapturerate=48000;sprop-stereo=0
a=ssrc:3488034365 msid:user1911957867@host-b7995bc8 webrtctransceiver0
a=ssrc:3488034365 cname:user1911957867@host-b7995bc8
a=mid:audio0
a=fingerprint:sha-256 DE:AA:B2:D9:DD:16:53:9F:00:93:EF:4A:EB:CF:18:20:28:92:E5:C8:5C:02:E3:77:99:58:85:01:F0:8D:AB:2A
m=audio 0 UDP/TLS/RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=setup:actpass
a=ice-ufrag:d7e3iCBCbG7Qs91L/nxfLmMytBN4IJGh
a=ice-pwd:L67u+Mac7Cy2L5Jwc++YpfUgddGhQn73
a=bundle-only
a=rtcp-mux
a=rtcp-rsize
a=sendrecv
a=rtpmap:111 OPUS/48000/2
a=rtcp-fb:111 nack pli
a=fmtp:111 sprop-maxcapturerate=48000;sprop-stereo=0
a=ssrc:1281434248 msid:user1911957867@host-b7995bc8 webrtctransceiver1
a=ssrc:1281434248 mslabel:ep2:1d0cefd7-f505-4ede-8eef-187ce67fc8f6
a=ssrc:1281434248 cname:user1911957867@host-b7995bc8
a=mid:audio1
a=fingerprint:sha-256 DE:AA:B2:D9:DD:16:53:9F:00:93:EF:4A:EB:CF:18:20:28:92:E5:C8:5C:02:E3:77:99:58:85:01:F0:8D:AB:2A

Resulting Janus Answer:
    v=0
    o=user1 53655765 2353687637 IN IP4 204.237.48.144
    s=-
    t=0 0
    a=group:BUNDLE audio0
    a=msid-semantic: WMS janus
    m=audio 9 UDP/TLS/RTP/SAVPF 111
    c=IN IP4 204.237.48.144
    a=recvonly
    a=mid:audio0
    a=rtcp-mux
    a=ice-ufrag:8eu2
    a=ice-pwd:PAI4lqP+n8M1iwpPKcy0LF
    a=ice-options:trickle
    a=fingerprint:sha-256 00:0B:2C:AE:90:7C:68:3F:67:0B:49:CA:17:F4:DA:68:E2:06:E7:84:51:32:C8:69:83:B7:00:BF:9A:D5:8E:61
    a=setup:active
    a=rtpmap:111 OPUS/48000/2
    a=fmtp:111 sprop-maxcapturerate=48000;sprop-stereo=0
    a=msid:janus janusa0
    a=ssrc:1439782350 cname:janus
    a=ssrc:1439782350 msid:janus janusa0
    a=ssrc:1439782350 mslabel:janus
    a=ssrc:1439782350 label:janusa0
    a=candidate:1 1 udp 2015363327 172.17.0.2 50320 typ host
    a=candidate:2 1 udp 1679819007 204.237.48.144 3787 typ srflx raddr 172.17.0.2 rport 50320
    a=end-of-candidates
    m=audio 0 UDP/TLS/RTP/SAVPF 0
    c=IN IP4 204.237.48.144
    a=inactive


For reference, here are the offer/answer for the LTR:

NoSip offer:
v=0
o=- 1681714812466801261 1 IN IP4 1.1.1.1
s=-
t=0 0
m=audio 20000 RTP/AVP 111
c=IN IP4 172.17.0.2
a=recvonly
a=rtpmap:111 OPUS/48000/2
a=rtcp-fb:111 nack pli
a=fmtp:111 sprop-maxcapturerate=48000;sprop-stereo=0
m=audio 20000 RTP/AVP 0
c=IN IP4 172.17.0.2
a=recvonly

LTR answer:
v=0
o=user1 53655765 2353687637 IN IP4 10.9.5.10
s=-
c=IN IP4 10.9.5.10
t=0 0
m=audio 6188 RTP/AVP 111
a=rtpmap:111 OPUS/48000/2
a=fmtp:111 sprop-maxcapturerate=48000;sprop-stereo=0
a=recvonly
m=audio 6189 RTP/AVP 0
a=recvonly

Patty Watson

unread,
Oct 7, 2021, 7:25:34 PM10/7/21
to meetecho-janus
I am hitting this line in sdp.c (as confirmed in the logs). So it would appear that Janus does not support multiple audio m-lines in the bundle. Am I misunderstanding this?

/* Check if we need to refuse the media or not */
if(m->type == JANUS_SDP_AUDIO) {
audio++;
/* Audio */
if(audio > 1) {
JANUS_LOG(LOG_WARN, "[%"SCNu64"] Skipping audio line (we have one already)\n", handle->handle_id);
m->port = 0;
}
}

Lorenzo Miniero

unread,
Oct 8, 2021, 3:19:43 AM10/8/21
to meetecho-janus
Ah then it won't work. The current version of Janus only one type of media stream per PeerConnection, so 1 audio + 1 video + 1 data max, not 2 audio streams. The multistream branch removes that constraint, but only some plugins support this right now, and neither the SIP nor the NoSIP plugin do at the moment.

L.
Reply all
Reply to author
Forward
0 new messages