Re: [MMUSIC] A proposal for how we would use the SDP that comes out of the MMUSIC interm

Byron Campen <> Fri, 09 October 2015 20:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7F2541AC3FD for <>; Fri, 9 Oct 2015 13:43:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7B9XymjSa8EF for <>; Fri, 9 Oct 2015 13:43:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6B1871AC3FB for <>; Fri, 9 Oct 2015 13:43:21 -0700 (PDT)
Received: by oiao187 with SMTP id o187so1529750oia.2 for <>; Fri, 09 Oct 2015 13:43:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=XfUSxCjL6vj0slwIDoOsjFFc3pV6q0oScIvkS1qsgic=; b=ooxE5VSdBXlqT47bUC2GCPpJN5kSNwhH8Cz+1cWMIcfOrNTRVSfu8bwJxmFNOtsUcQ 6aXy2uod9AK66PcOucQsxWx7ixn7/pL0hfhMKZB1MY4VzssIgE3OxQO9RrFlExpQ2lyv NHbIls40U9Ge7zoJKKrors2W77ASoqUChrd3opeQYh1ZLwUHWmpS4xpkyRdm/kTVx80q IDTKCwXJou0Q2Blhd4bd2hYxec29RCa/mVyetBd9sszD02naVSwanGsHXm+UYQ8mt0RY 0a7zaRlqqT6PVHEM4bi55khU2Wb3/IcfmGKC7yjhd1LM1nzefCLZXdPbf2DMW0bFLISL 4CpA==
X-Received: by with SMTP id y139mr9096650oia.64.1444423400739; Fri, 09 Oct 2015 13:43:20 -0700 (PDT)
Received: from ?IPv6:2602:306:83ae:c480:ca1:59fd:a204:3645? ([2602:306:83ae:c480:ca1:59fd:a204:3645]) by with ESMTPSA id t207sm1504779oie.13.2015. for <> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Oct 2015 13:43:19 -0700 (PDT)
References: <> <> <>
From: Byron Campen <>
Message-ID: <>
Date: Fri, 9 Oct 2015 15:43:18 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------070903090001070206020408"
Archived-At: <>
Subject: Re: [MMUSIC] A proposal for how we would use the SDP that comes out of the MMUSIC interm
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 09 Oct 2015 20:43:23 -0000

On 10/9/15 12:56 PM, Peter Thatcher wrote:
> If the JS wants to send more information about what semantics it is 
> giving to each encoding/rsid, it is more than capable of doing so in 
> its signalling to the server.  We don't need to put all signalling 
> into SDP.
> We may choose, for convenience of the JS, to put a minor amount of 
> signalling in the JS, like we put the track ID into the SDP.  If so, 
> what you're really advocating for is an RSID that's a string instead 
> of an int:
     I thought about this (in fact, the rid value is already a string so 
you could do this with the present draft), but I'm not exactly happy 
with it. I appreciate the temptation to say that since this is webrtc, 
it is ok to just have the application hard-code stuff(eg; the meaning of 
the rid value "small"), and disallow any negotiation, but these are not 
properties you typically find in an IETF spec, for good reason.

     That said...
> ​I would point out, though, that the conference server really doesn't 
> need to know anything about the RSIDs.  It already knows the sizes of 
> the layers from the media itself and can just use that to choose what 
> to forward.  ​It just needs the RSIDs to know which FEC or RTX stream 
> goes with which layer.
> might be doable to allow parameterless rid for send with the 
understanding that the receiver will figure out what to do by watching 
the RTP, _probably_ with an eye toward overall bitrate (since a lot more 
can vary besides resolution). This requires no hard-coding of semantics 
for "small", which is good. This is harder to implement, though. 
Ultimately, you're going to need to bring this idea to mmusic, the 
sooner the better.
>     Regarding PT demux, it is fine if we do not support sending an
>     offer with PT demux, but if a conferencing server sends us an
>     offer that uses PT demux, we kinda have to play along.
>     ​ ​
>     mmusic is not going to be happy if we say we'll reject such an
>     offer in rtcweb-jsep.
> ​
> ​ What goes out in the offer matters very little.  It's what goes out 
> as RTP that really matters.  And saying that the conference server can 
> request PT-based simulcast is 99% the way there to saying PT-based 
> simulcast is fully required ​
> ​
> ​ in WebRTC 1.0.  And I'm opposed to that.  ​
> ​
> If that's a requirement for simulcast in WebRTC 1.0, then I'd rather 
> have simulcast not be in 1.0.​
> ​  ​
> I think it is a valid choice to say WebRTC will only use a 
> non-PT-based subset of the MMUSIC work.  There's *a lot* of SDP out 
> there that WebRTC doesn't support, and PT-based simulcast would just 
> be one more of those things.
    I don't like PT demux any more than you, but what you're talking 
about here is implementing part of a spec, but omitting mandatory parts 
of it. This is not subsetting. You need to bring your objections to 
mmusic. There may be some compromise that can be worked out there.

Best regards,
Byron Campen