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

From: "Roni Even" <[email-masked]>
Date: Mon, 13 Feb 2012 13:21:11 +0200

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Feb 2012 10:57:50 -0500

On 2/13/12 6:21 AM, Roni Even wrote:
> 1.The co-relation between the media capture and the codec information in
> the offer answer
>
> 2.Multiplexing multiple media streams.
>

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

Using that solution means that there will be one or more lines in the 
SDP for each capture that *might* be carried. In the case of a large 
conference and switched streams this could potentially be hundreds of 
captures. I expect that having an SDP with hundreds of m-lines will 
likely be considered unacceptable.

I presume you are assuming somehow the number of m-lines need not be so 
great. I guess that means that either its limited to conferences with 
fewer total captures, or else that the number of captures described in 
SDP can be very limited compared to the total number that exist.

Can you elaborate your thinking?

	Thanks,
	Paul

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 13 Feb 2012 11:08:13 -0500

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
[email-masked]

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

Hi,

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

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

---

From: "Roni Even" <[email-masked]>
Date: Mon, 13 Feb 2012 20:00:28 +0200

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:[email-masked]] 
Sent: Monday, February 13, 2012 6:08 PM
To: Roni Even; [email-masked]
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

[email-masked]

Hi,

Roni

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Feb 2012 13:16:07 -0500

Roni - at end

On 2/13/12 1:00 PM, Roni Even wrote:
> 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.
>
> 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.

Suppose we have an MCU with many (e.g. hundreds) of captures coming into it.

And then suppose the MCU wants to advertise a switched capture that 
switches among all of those.

IIUC, you would represent that as a single m-line for the switched 
capture, but with any one of the many SSRCs indicating which capture was 
being sent at any given time.

But then how does the recipient discover which of the switched captures 
it is receiving? And how does it sort out which SSRCs correspond to the 
switched capture, vs. others that correspond to other captures in the 
capture set mapped to the same RTP addr/port?

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Mon, 13 Feb 2012 20:45:48 +0200

Hi Paul,
This is what the conference event package is for
Roni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Kyzivat
> Sent: Monday, February 13, 2012 8:16 PM
> To: [email-masked]
> Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0
> 
> Roni - at end
> 
> > 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.
> >
> > 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.
> >
> > 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.
> >
> capture, but with any one of the many SSRCs indicating which capture
> was being sent at any given time.
> 
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Feb 2012 16:50:22 -0500

> This is what the conference event package is for

Hmm. Maybe there is some way to make that work. But I'm not convinced.
I think the discussion of RTP usage this week will be lively and 
mutually educational.

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Wed, 15 Feb 2012 06:02:10 +0200

Hi Paul,
I think that the discussion should start with the ground rules.
My assumption is that we have a SIP offer/answer that provides in the SDP
all the RTP streams that may be used with the relevant parameters like
profile and level and the other optional parameters. In parallel we have the
CLUE information which describes the semantics of the streams based on
purpose and co-ordinates.
There need to be mapping between them.
For multipoint case if we want to convey what we call roster information
there is the conference event package.
BR
Roni

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, February 14, 2012 11:50 PM
> To: Roni Even
> Cc: [email-masked]
> > This is what the conference event package is for Roni
> 
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Paul Kyzivat
> >>> 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.
> >>>
> >>> 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
> >>> 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
> >>> 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.
> >>>
> >> But then how does the recipient discover which of the switched
> >> captures it is receiving? And how does it sort out which SSRCs
> >> correspond to the switched capture, vs. others that correspond to
> >> other captures in the capture set mapped to the same RTP addr/port?
> >>
> >> 	Thanks,
> >> 	Paul

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Tue, 14 Feb 2012 21:35:17 -0800

Perhaps I've misunderstand what you meant Roni, but I am surprised by
your comment.
Ground rules? Aren't we considering alternate architectures that work
best, rather than having ground-rules based on assumptions on how things
will be done?

Don't we have a ways to go yet to understand where offer/answer is
viable for CLUE, and where it is not? and then to evaluate different
possible solutions for where the current infrastructure may not work for
CLUE?

Allyn 

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Roni Even
> Sent: Tuesday, February 14, 2012 8:02 PM
> To: 'Paul Kyzivat'
> Cc: [email-masked]
> > >>> description on the semantics of the data. Stream is the RTP
> stream.
> > >> In
> > >>> Now I am not sure what you mean when you are talking about
> hundreds
> > >> of
> > >>> descriptions.
> > >>>
> > >>> I do not see an endpoint receiving hundreds of streams or a
large
> > >> full
> > >> Suppose we have an MCU with many (e.g. hundreds) of captures
> coming
> > >> into it.
> > >>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Feb 2012 08:36:47 +0100

Hi,

Just a reminder, that BUNDLE is only about multiple m- lines sharing the same port number. It does not prevent you from, within a single m- line, e.g. having multiple SSRC-multiplexed streams.

One of the ideas in RTCWEB has been to have one audio m- line, and one video m- line, sharing the same port number (using BUNDLE), but those m- lines can then contain multiple streams.

Regards,

Christer

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jonathan Lennox
Sent: 13. helmikuuta 2012 18:08
To: Roni Even; [email-masked]
Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0

Hi, Roni -

-
Jonathan Lennox
[email-masked]

Hi,

---

From: "Roni Even" <[email-masked]>
Date: Wed, 15 Feb 2012 12:00:16 +0200

Allyn,
Do you see CLUE replacing any of the SDP information like describing all the
RTP streams that will be sent and received in a call?
For example for a video switch MCU do you see the following done in CLUE and
not in SDP?

m=video 49170 RTP/AVP 98
      a=ssrc:SSRC-B cname:CNAME-B
      a=ssrc:SSRC-C cname:CNAME-C
      a=ssrc:SSRC-D cname:CNAME-D
      a=ssrc:SSRC-B fmtp:98
        sprop-parameter-sets=<parameter sets data#B>
      a=ssrc:SSRC-C fmtp:98
        sprop-parameter-sets=<parameter sets data#C>
      a=ssrc:SSRC-D fmtp:98
        sprop-parameter-sets=<parameter sets data#D>
      a=rtpmap:98 H264/90000
      a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0
        packetization-mode=1

Roni

> From: Allyn Romanow (allyn) [mailto:[email-masked]]
> Sent: Wednesday, February 15, 2012 7:35 AM
> To: Roni Even; Paul Kyzivat
> Cc: [email-masked]
> best, rather than having ground-rules based on assumptions on how
> things will be done?
> 
> possible solutions for where the current infrastructure may not work
> for CLUE?
> 
> Allyn
> 
> 
> > My assumption is that we have a SIP offer/answer that provides in the
> > SDP all the RTP streams that may be used with the relevant parameters
> > like profile and level and the other optional parameters. In parallel
> > we have the CLUE information which describes the semantics of the
> > streams based on purpose and co-ordinates.
> > For multipoint case if we want to convey what we call roster
> > information there is the conference event package.
> > BR
> > Roni
> >
> > > >>> SDP I do not differentiate between the case where you have an
> m-
> > > line
> > > >>> In the point to point the number of RTP streams described in
> the
> > > SDP
> > > >>> distributed signaling. In this case the MCU receives all MCs
> and
> > > the
> > > >>> bundle) that will allow him to send and receive the maximum
> that
> > > the

---

From: "Roni Even" <[email-masked]>
Date: Wed, 15 Feb 2012 12:06:19 +0200

Hi Christer,

I assume BUNDLE allows you also to provide the multiplexing information also
for multiple m-lines of the same media type, one example if they represent
different contend using the SDP content attribute to describe each stream.
It provides you one more degree a freedom when describing the media streams

Roni

From: Christer Holmberg [mailto:[email-masked]] 
Sent: Wednesday, February 15, 2012 9:37 AM
To: Jonathan Lennox; Roni Even; [email-masked]
Subject: RE: [clue] comment on draft-lennox-clue-rtp-usage-0

Hi,

Just a reminder, that BUNDLE is only about multiple m- lines sharing the
same port number. It does not prevent you from, within a single m- line,
e.g. having multiple SSRC-multiplexed streams.

One of the ideas in RTCWEB has been to have one audio m- line, and one video
m- line, sharing the same port number (using BUNDLE), but those m- lines can
then contain multiple streams.

Regards,

Christer

  _____  

Hi, Roni -

- 

Jonathan Lennox

[email-masked]

Hi,

Roni

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Feb 2012 11:18:24 +0100

Hi, 

> I assume BUNDLE allows you also to provide the multiplexing information also for multiple m-lines of the same media type, one 
> example if they represent different contend using the SDP content attribute to describe each stream. It provides you one more 
> degree a freedom when describing the media streams

Sure. BUNDLE does not put any restrictions on the number of m- lines, number of m- lines with the same media type, etc.

Regards,

Christer

Hi,

Regards,

Christer

Hi, Roni -

- 

Jonathan Lennox

[email-masked]

Hi,

Roni

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Wed, 15 Feb 2012 06:55:45 -0800

Hi Roni,

Excellent question, thanks for clarifying your comment. No, I don't see
CLUE replacing this SDP information.

> Sent: Wednesday, February 15, 2012 2:00 AM
> To: Allyn Romanow (allyn); 'Paul Kyzivat'
> Cc: [email-masked]
> > > > >>> draft still has an m-line for each RTP stream. The
difference
> > is
> > > > >>> should probably be the number of media captures in the
> capture
> > > set
> > > > >>> In the multipoint case I assume that we are only talking
> about
> > an
> > > > >>> SDP from all end point it needs to provide all MCs if it
> wants
> > > but
> > > > >>> end point will receive simultaneously. The content of each
of
> > > these
> > > > >>> streams will be two. The content inside will change using
the
> > > SSRC
> > > > >> And then suppose the MCU wants to advertise a switched
capture
> > > > >> correspond to the switched capture, vs. others that
correspond
> > to

---

From: Michael Hammer <[email-masked]>
Date: Wed, 15 Feb 2012 15:22:37 -0500

I have been watching this topic loosely to see how it develops.
But, that is not always easy to follow.

I like the analogy of the SDP defining who is on the roster of players that
can be sent onto the pitch/field.
Whereas, the new stuff defines who is actually playing at the moment and in
what position.

I would not expect the lineup sent to the referee to have to provide the
height/weight and whatever stats ad nauseum of the player.
So, would hope that those details are confined to the SDP and not
replicated redundantly.
A reference to each component should be sufficient, no?
Also, do you expect to have free agents added to the roster at any time?
That might be a new SDP offer/answer.  (Does offer/answer also refer to the
new stuff?)

What is also not clear, not even within this thread is whether (perhaps
unlike SDP) the sender is defining who should be on the field,
or whether the crowd watching (receivers) are defining what is sent.
Does the MCU define a consistent view of the game for everyone?
Or, does each receiver command this and everyone gets their own view?

>From the peanut gallery,
Mike