Re: [clue] comment on draft-lennox-clue-rtp-usage-0

["Roni Even" <[e-mail]>]

Hi Jonathan,

First to clarify, when I say media capture I refer to the CLUE description
on the semantics of the data. Stream is the RTP stream. In SDP I do not
differentiate between the case where you have an m-line for each RTP media
stream or you multiplex them using SSRC. The bundle draft still has an
m-line for each RTP stream. The difference is that without bundle they each
one is an RTP session while in the bundle case at least for now they are all
part of the same RTP session.

 

Now I am not sure what you mean when you are talking about hundreds of
descriptions.

In the point to point the number of RTP streams described in the SDP should
probably be the number of media captures in the capture set entry with the
largest number of MCs, see the draft I submitted yesterday.

In the multipoint case I assume that we are only talking about an MCU that
serves as a central signaling point and not about some distributed
signaling. In this case the MCU receives all MCs and the SDP from all end
point it needs to provide all MCs if it wants but as for the SDP it only
need to provide the number of m-lines (using bundle) that will allow him to
send and receive the maximum that the end point will receive simultaneously.
The content of each of these RTP streams or channels will change based on
the current configured capture set entry. For example in your 2 out of three
the number of m-lines or RTP streams will be two. The content inside will
change using the SSRC to identify the specific one. BTW: I think that it
will work better if all three VC use the same codec.

I do not see an endpoint receiving hundreds of streams or a large full mesh
conference as a valid use case.

 

In your draft you do not address the relation between the codec information
(What I mean is all the codec parameters in the m-line) but they exist and
need to be conveyed to the consumer with the realtion to the MC to allow the
consumer to know what he is currently receiving.

 

Roni

 

From: Jonathan Lennox [mailto:[e-mail]] 
Sent: Monday, February 13, 2012 6:08 PM
To: Roni Even; [e-mail]
Subject: RE: [clue] comment on draft-lennox-clue-rtp-usage-0

 

Hi, Roni -

 

I don't think my draft discusses "codec information" at all, at least as I
understand the term, so I'm not sure quite what you mean by it.

 

As for BUNDLE, I think it'll emerge that it doesn't work or scale well for
complicated cases (e.g., cases where you have many potential captures, or
where a source moves between captures, or where a single source could be
sent for more than one capture simultaneously).

 

Also, to avoid confusion, when you say "stream," what do you mean?  The term
(unfortunately) means very different things in SDP and in RTP - in the
former case, it's the thing identified by an m= line (and thus, pre-BUNDLE,
a transport flow), whereas in the latter case, it's the thing identified by
an SSRC.  So I'm not quite sure what your draft, and this e-mail, is
discussing.

 

- 

Jonathan Lennox

[e-mail]

 

From: Roni Even [mailto:[e-mail]] 
Sent: Monday, February 13, 2012 6:21 AM
To: [e-mail]
Subject: [clue] comment on draft-lennox-clue-rtp-usage-0

 

Hi,

My view is that there are two separate problems that the draft discusses:

 

1.       The co-relation between the media capture and the codec information
in the offer answer

2.       Multiplexing multiple media streams.

 

I think that the second problem is addressed in
http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-bundle-negotiation-00 

As for the mapping I have a proposal to use a capture set group in the SDP
for the ampping

Roni