Subject: [clue] CLUE SDP signaling and MMUSIC unfied plan - issues raised in the interim

From: "Roni Even" <[email-masked]>
Date: Wed, 18 Sep 2013 12:20:56 +0300

Hi,

At the CLUE interim meeting (September 17th) this issue was brought out as
part of the RTP mapping presentation.

MMSUSIC decided to use the "unified" plan for RTCweb. The plan propose that
an m-line will describe a media source or media stream track. In CLUE terms
this is a media capture.

The data from a media source can be encoded as a single or multiple media
streams (RTP media stream) or CLUE capture encodings. Examples for the
multiple media streams may be a simulcast proposal of different resolutions
streams or a FEC (forward error correction) stream to protect the media
stream.

The CLUE signaling draft (individual draft) propose that each SDP m-line
represent a capture encoding and uses the SDP label attribute to map SDP
information to CLUE.  This does not work with "unified" plan since the label
attribute is an SDP media level attribute.

 

http://tools.ietf.org/id/draft-even-mmusic-application-token-01.txt discuss
some of the issues with using an SDP m-line to describe a media source
including support for FEC and simulcast. The simulcast support refers to
http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-02.

Note that a FEC stream can protect multiple media capture (one FEC stream
protect all three RTP streams from the three cameras)

I also think that "bundle" is not an issue since it does not care what an
m-line describes.

Some questions to discuss

1.       Does CLUE want to support unified or have an SDP m-line describe a
media source or do we have an m-line describe a capture encoding or media
stream (the relations between the m-line can be described SDP group
attribute or in the CLUE protocol)

2.       How do we describe the FEC stream. This is not a media stream and
it is not really a capture encoding. So do we only have it in the SDP and no
representation in CLUE. This will mean that it is not part of an encoding
group so the total bandwidth limit will be based on SDP and not only on the
encoding group. (this will relate also to the discussion about how do we
describe the limits for encoding group (CLUE or SDP).

Currently the authors of the RTP mapping draft (Jonathan and I) are going to
update the document assuming that an m-line represent a capture encoding
(not "unified") and that FEC is only described in SDP.

Please look at the application token draft and provide feedback

Thank

Roni Even

---

From: Christian Groves <[email-masked]>
Date: Tue, 01 Oct 2013 14:51:51 +1000

Hello Roni,

Please see my comments below.

Regards, Christian

On 18/09/2013 7:20 PM, Roni Even wrote:
>
> Hi,
>
> At the CLUE interim meeting (September 17^th ) this issue was brought 
> out as part of the RTP mapping presentation.
>
> MMSUSIC decided to use the “unified” plan for RTCweb. The plan propose 
> that an m-line will describe a media source or media stream track. In 
> CLUE terms this is a media capture.
>
> The data from a media source can be encoded as a single or multiple 
> media streams (RTP media stream) or CLUE capture encodings. Examples 
> for the multiple media streams may be a simulcast proposal of 
> different resolutions streams or a FEC (forward error correction) 
> stream to protect the media stream.
>
> The CLUE signaling draft (individual draft) propose that each SDP 
> m-line represent a capture encoding and uses the SDP label attribute 
> to map SDP information to CLUE. This does not work with “unified” plan 
> since the label attribute is an SDP media level attribute.
>
> http://tools.ietf.org/id/draft-even-mmusic-application-token-01.txt 
> discuss some of the issues with using an SDP m-line to describe a 
> media source including support for FEC and simulcast. The simulcast 
> support refers to 
> Note that a FEC stream can protect multiple media capture (one FEC 
> stream protect all three RTP streams from the three cameras)
>
> I also think that “bundle” is not an issue since it does not care what 
> an m-line describes.
>
> 1.Does CLUE want to support unified or have an SDP m-line describe a 
> media source or do we have an m-line describe a capture encoding or 
> media stream (the relations between the m-line can be described SDP 
> group attribute or in the CLUE protocol)
>
[CNG] Do you mean "Does CLUE want to support unified AND and have an SDP 
m-line...."? To use CLUE I don't think we should have to rely on 
"unified" however we shouldn't preclude the use of CLUE in systems that do.

> 2.How do we describe the FEC stream. This is not a media stream and it 
> is not really a capture encoding. So do we only have it in the SDP and 
> no representation in CLUE. This will mean that it is not part of an 
> encoding group so the total bandwidth limit will be based on SDP and 
> not only on the encoding group. (this will relate also to the 
> discussion about how do we describe the limits for encoding group 
> (CLUE or SDP).
>
> Currently the authors of the RTP mapping draft (Jonathan and I) are 
> going to update the document assuming that an m-line represent a 
> capture encoding (not “unified”) and that FEC is only described in SDP.
>
[CNG] Describing FEC only in SDP seems logical. Its not really metadata 
regarding the content of the capture.
> Please look at the application token draft and provide feedback
[CNG] I had a look and thought I understood it but then I re-read it and 
ended up confused.

The examples show the use of the a=appID:<token> however there's nothing 
with a=extmap:1 urn:ietf:params:rtp-hdrext:App-ID ? I take it the use of 
a=aapID is no use for CLUE unless you use either the rtp hearer 
extension of SDES?

Sect.3 of the draft indicates to use the token from the unified draft. 
This is specified as "MUST contain at least 32 characters chosen 
randomly from full set of 79 characters allowed in a token". So rather 
than a single digit token i.e. a=appID:2, a more realistic use a 32 
character token?
>
> Thank
>
> Roni Even
>
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue