W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2016

Re: Issue 685: Update JSEP reference for receipt of multiple RTP encodings

From: Bernard Aboba <Bernard.Aboba@microsoft.com>
Date: Mon, 15 Aug 2016 19:01:01 +0000
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <DM2PR21MB00757F49A7432F5F64037BFDEC120@DM2PR21MB0075.namprd21.prod.outlook.com>
Peter Thatcher said:

"My understanding is that:

1. WebRTC 1.0 endpoints can receive (if the endpoint supports it well, which I know some do not) more than one source RTP streams into a single RtpReceiver as long as it's only "one at a time", AKA switching. Once we right down the demux rules for JSEP, this should become more obvious. The only issue there that I know of is dealing with clock synchronization between SSRCs.

2. WebRTC 1.0 endpoints cannot receive multiple source RTP streams simultaneously into a single RtpReceiver. So, it depends on your definition of "receive simulcast". If it's "receive one stream at a time being forwarded by an SFU that's receiving many" (#1<https://github.com/w3c/webrtc-pc/pull/1>), then yes. If it's "receive many streams at a time" (#2<https://github.com/w3c/webrtc-pc/pull/2>), then no."

[BA]  Currently we have RTCRtpSender.setParameters(), which makes it possible to set RTCRtpEncodingParameters in order to send simulcast streams (e.g. the attributes denoted as "Sender" below):

Attribute

Type

Receiver/Sender

Read/Write

ssrc

unsigned long

Receiver/Sender

Read-only

fec

RTCRtpFecParameters

Receiver/Sender

Read-only

rtx

RTCRtpRtxParameters

Receiver/Sender

Read-only

active

boolean

Sender

Read/Write

priority

RTCPriorityType

Sender

Read/Write

maxBitrate

unsigned long

Sender

Read/Write

maxFramerate

unsigned long

Sender

Read/Write

scaleResolutionDownBy

double

Sender

Read/Write

rid

DOMString

Receiver/Sender

Read-only



However, there is no equivalent RTCRtpReceiver.setParameters() method so that a browser cannot generate an SDP Offer indicating the desire to receive simulcast.

However, an SFU could generate an Offer indicating the ability to both receive and send simulcast.

If this SDP is then passed to setLocalDescription() or setRemoteDescription() what happens?   The specification currently is not clear about this.

If a browser can support simulcast reception, it could generate an Answer indicating the ability to both receive and send simulcast.

If the browser can support reception of simulcast, would a call to RTCRtpReceiver.getParameters() then return RTCRtpEncodingParameters indicating details of the simulcast streams to be received?















   m=audio 10000 RTP/SAVPF 96 9 8 0 123

   a=rtpmap:96 OPUS/48000

   a=rtpmap:9 G722/8000

   a=rtpmap:8 PCMA/8000

   a=rtpmap:0 PCMU/8000

   a=rtpmap:123 telephone-event/8000

   a=mid:a1

   ...

   m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107

   a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id

   a=rtpmap:98 VP8/90000

   a=fmtp:98 max-fs=3600; max-fr=30

   a=rtpmap:99 VP9/90000

   a=fmtp:99 max-fs=3600; max-fr=30

   a=rtpmap:100 H264/90000

   a=fmtp:100 profile-level-id=42401f; packetization-mode=0

   a=rtpmap:101 H264/90000

   a=fmtp:101 profile-level-id=42401f; packetization-mode=1

   a=rtpmap:102 H264/90000

   a=fmtp:102 profile-level-id=640c1f; packetization-mode=0

   a=rtpmap:103 H264/90000

   a=fmtp:103 profile-level-id=640c1f; packetization-mode=1

   a=rtpmap:104 H264-SVC/90000

   a=fmtp:104 profile-level-id=530c1f

   a=rtpmap:105 H264-SVC/90000

   a=fmtp:105 profile-level-id=560c1f

   a=rtpmap:106 H265/90000

   a=fmtp:106 profile-id=1; level-id=93

   a=rtpmap:107 H265/90000

   a=fmtp:107 profile-id=2; level-id=93

   a=sendrecv

   a=mid:v1 (max resolution)

   a=rid:1 send max-width=1280;max-height=720;max-fps=30

   a=rid:2 recv max-width=1280;max-height=720;max-fps=30

   ...

   m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107

   a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id

   ...same rtpmap/fmtp as above...

   a=recvonly

   a=mid:v2 (medium resolution)

   a=rid:3 recv max-width=640;max-height=360;max-fps=15

   ...

   m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107

   a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id

   ...same rtpmap/fmtp as above...

   a=recvonly

   a=mid:v3 (medium resolution)

   a=rid:3 recv max-width=640;max-height=360;max-fps=15

   ...

   m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107

   a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id

   ...same rtpmap/fmtp as above...

   a=recvonly

   a=mid:v4 (small resolution)

   a=rid:4 recv max-width=320;max-height=180;max-fps=15

   ...

   m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107

   a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id

   ...same rtpmap/fmtp as above...

   ...same rid:4 as above for mid:v5,v6,v7 (small resolution)...

   ...
Received on Monday, 15 August 2016 19:01:36 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:49 UTC