Subject: [clue] FW: New Version Notification for draft-even-clue-rtp-mapping-01.txt

From: Roni even <[email-masked]>
Date: Mon, 12 Mar 2012 09:26:29 +0000

Hi,
I updated the draft that I submitted before the interim meeting
Roni

________________________________________
From: [email-masked] [[email-masked]]
Sent: Monday, March 12, 2012 11:20
To: Roni even
Subject: New Version Notification for draft-even-clue-rtp-mapping-01.txt

A new version of I-D, draft-even-clue-rtp-mapping-01.txt has been successfully submitted by Roni Even and posted to the IETF repository.

Filename:        draft-even-clue-rtp-mapping
Revision:        01
Title:           Mapping RTP streams to CLUE media captures
Creation date:   2012-03-12
WG ID:           Individual Submission
Number of pages: 9

Abstract:
   This document describes mechanisms and recommended practice for
   mapping RTP media streams defined in SDP to CLUE media captures.

The IETF Secretariat

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Mar 2012 12:44:43 -0400

Roni,

IIUC, you are proposing that the initial offer from an MCU would include 
the RTP streams required for all of the MCs it is advertising. Is that 
right?

And each such stream would call for the maximum bandwidth required by 
any MC mapped to that stream?

That might be excessive if the other end ultimately selects fewer MCs.

(Whether those are significant issues can be discussed later.)

I also don't understand how the mapping of MCs to m-lines via RTP-id 
works once you consider that both ends are sending media. After the o/a 
exchange there must be a single set of m-lines. According to RF5888, the 
mid value in the affer MUST be the same as the mid value in the answer. 
That means the answerer can't insert its own mid values corresponding to 
its RTP-id values. Also, the m-lines in the answer are constrained by 
the m-lines in the offer.

The only fix I see for this is to first exchange advertisements (and 
maybe selections too), then compute a set of m-lines that are sufficient 
to handle the bidirectional exchange of MCs, and then exchange an o/a 
for that.

Maybe there is another way. In any case I think this needs to be 
addressed in the draft.

	Thanks,
	Paul (as individual)

---

From: "Roni Even" <[email-masked]>
Date: Mon, 12 Mar 2012 22:24:09 +0200

Hi Paul,
I think that the major focus is point to point but see inline
Roni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Kyzivat
> Sent: Monday, March 12, 2012 6:45 PM
> To: [email-masked]
> Subject: Re: [clue] FW: New Version Notification for draft-even-clue-
> rtp-mapping-01.txt
> 
> Roni,
> 
> IIUC, you are proposing that the initial offer from an MCU would
> include the RTP streams required for all of the MCs it is advertising.
> Is that right?

Roni: the initial offer should include RTP stream for the simultaneous Media
capture that the endpoint specified (for example there is no need to have a
separate m-line for a media capture coming from the same camera but offering
different view like zoom out and zoom in view). The m-line provide
information about the encoder which is a physical entity that in CLUE can be
used to provide different content that is defined by the CLUE protocol. If
it is an MCU it is an application decision what is the simultaneous set  it
wants to distribute. My view is that it is what you also called a "virtual
room" that describes a common set for a conference that the MCU wants to
use, the MCU has also physical encoder constrains similar to an end point.

> any MC mapped to that stream?

Roni: I assume that you are asking about MCU case. If the conference is not
transcoding the MCU will offer to the participants the bw of the common mode
which is likely to be the minimum of all participants. BTW: this is not a
CLUE issue it applies to any MCU that does non transcoded video conferences
> That might be excessive if the other end ultimately selects fewer MCs.
Roni: the bw is per m-line (using b=TIAS:) and per the SDP session (using
b=AS: so if it uses less m-lines than less bw will be used as long as the
total is less than the SDP session bw parameter.

> exchange there must be a single set of m-lines. According to RF5888,
> the mid value in the affer MUST be the same as the mid value in the
> answer.
> That means the answerer can't insert its own mid values corresponding
> to its RTP-id values. Also, the m-lines in the answer are constrained
> by the m-lines in the offer.
> 
> maybe selections too), then compute a set of m-lines that are
> sufficient to handle the bidirectional exchange of MCs, and then
> exchange an o/a for that.

Roni: this is a good point and I will need to address it. Your proposal is
one option.
I think that even of offering a full set in the initial offer it is based on
what the offerer can send and receive using sendonly and recvonly attribute
if it has different encoding and decoding resources. If the offer for
example has three screens and cameras and the answer have one screen one
camera and decode more than one stream it can either use recvonly attribute
or after responding to the offer start a second offer/answer exchange to
addree the asymmetry. CLUE also need two exchanges requiring advertisements
from both sides. I assume this is the limitation of RFC3264 and SDP while if
using H.245 you specify receive and transmit capabilities (maybe use H.245
for CLUE)

> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Mar 2012 17:38:42 -0400

Comments inline.

> I think that the major focus is point to point but see inline

I think both need to be addressed.

> wants to distribute.

But it must be consistent with the advertisement it is providing, right?

And then it can get negotiated down from there if the other end selects 
less that was advertised? (E.g. if only a subset of the MCs in a Scene 
Entry are selected.)

Or do you see a case where the initial offer doesn't cover the full 
advertisement?

> My view is that it is what you also called a "virtual
> Roni: I assume that you are asking about MCU case.

I don't think it matters.

> If the conference is not

I was asking about something else.

Some scene entries may have more MCs than others. The MCs of one scene 
entry can share m-lines with the MCs of other scene entries. But for any 
one m-line the bw requirement for the offer must be the maximum of the 
bw required for each MC mapped to that m-line.

> total is less than the SDP session bw parameter.

But will the bw be initially allocated, risking call failure if it isn't 
available, even if less will actually be needed? What, if anything, are 
you assuming about bandwidth management?

> Roni: this is a good point and I will need to address it. Your proposal is

I realized it was a problem, but didn't think much about solutions.
My point was just to get discussion going on it.

Actually I think this is a general problem for bundle, and probably 
needs to be discussed as part of the bundle proposal, on the mmusic list.

> if it has different encoding and decoding resources.

You mean using different m-lines for each direction?

Perhaps that is part of an answer, but if so it will take some working 
out. I think many/most vanilla sip endpoints won't work right if offered 
separate sendonly and recvonly m-lines.

Also, while this could resolve the problem of binding m-lines to 
RTP-ids, it couldn't do so in one o/a cycle unless the initial offerer 
has received and advertisement from the answerer prior to the first offer.

> If the offer for
> addree the asymmetry.

I'm not sure I follow the above. For the answerer to reuse any of the 
offered m-lines for sending media it will have to construct its 
advertisement to use the RTP-ids from those included in the offer. If 
those aren't suitable, then it will need to answer with recvonly for 
those m-lines that aren't being reused, and then initiate a new o/a that 
adds more m-lines.

> CLUE also need two exchanges requiring advertisements
> from both sides. I assume this is the limitation of RFC3264 and SDP

yes

> while if

Out of scope for CLUE.

	Thanks,
	Paul