Subject: Re: [AVT] Working group last call: draft-ietf-avt-topologies-03

From: Colin Perkins <[email-masked]>
Date: Thu, 11 Jan 2007 12:38:50 +0000

There were a number of comments received on the topologies draft. We  
expect a revised draft will be submitted, followed by a second  
working group last call.

Colin

On 8 Dec 2006, at 17:43, Even, Roni wrote:
> This is to announce a working group last call on the RTP Topologies.
>
> Due to the holiday season we will extend the last call period to  
> four weeks.
> Please send any final comments to the mailing list by January 5th  
> 2007.
>
> If no issues are raised, we will request the IESG consider this for  
> publication as an Informational RFC.
>
>
> ----------------------------------------------------------------------
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
> This draft is a work item of the Audio/Video Transport Working  
> Group of the IETF.
>
> 	Title		: RTP Topologies
> 	Author(s)	: M. Westerlund, S. Wenger
> 	Filename	: draft-ietf-avt-topologies-03.txt
> 	Pages		: 17
> 	Date		: 2006-12-1
> 	
> This document discusses multi-endpoint topologies commonly used in
>    RTP based environments.  In particular, centralized topologies
>    commonly employed in the video conferencing industry are mapped to
>    the RTP terminology.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-avt-topologies-03.txt
>
> Roni Even
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 17 Jan 2007 14:23:55 +0100

Hi Roni,

Thanks for the review.

Even, Roni skrev:
> Sorry, I sent the previous email too early.
> 
> Hi,
> Reviewed the drafts I think it is important work.
> As for comments
> 
> 1. In section 3.3 you discuss about translator, I assume that you are addressing only RTP translators even when you are talking about media translators ruling out translation between RTP and non-RTP like for example a media GW between an IP and circuit switch network. This has to do with the SSRC space which is not available in non RTP transport.

Well, we are discussing translators as defined in RTP. They can include 
to some degree gateways, but not all types.

> 
> 2. When talking about figure 4 you describe a simple transport translator. Do you mean that all RTP and RTCP traffic is just relayed by the MCU. I am not sure how RTCP maximum rate is kept if all RTCP traffic is relayed. What about RTP rate will it be asymmetric. 

The RTCP rate will be maintained as if one forwards all RTCP traffic to 
everyone then all participants will see all other participants and thus 
adjust their values of the sender and receiver count. That will mean 
that the RTCP transmission scheduling algorithm will keep the RTCP 
bandwidth within the bounds provided by the session management tool. If 
one declare different values for different participants then one will 
end up with that some participants may receive more than the declared 
value due to this.

In practice this is not any different from using ASM. The only 
difference is that participants sends to a translator that performs the 
distribution rather than the network layer itself.

> 
> 3. In the same paragraph you mention this as a common MCU scenario. I would not agree since a switching MCU will still terminate the RTCP stream and if SRTP is used it will need to be trusted in order to look at the RTCP to acts on the controls in the RTCP stream. You state it in section 3.5 that this architecture is not common, so why have it?

I assume that is the following sentnece "A common MCU scenario is the 
one depicted in Figure 4." that you object against. We can remove common 
to not provide any judgment on how common this really is implemented.

However I get confused with the remaining text. Is it something in 
section 3.3, or is it something in 3.5 that is the problem?

However I can comment that Section 3.5 is included for completes. The 
draft is intended to discuss different possible topologies and there 
advantages and disadvantages. Thus even if not common it warrants the 
inclusion.

> 
> 4. In section 3.5 you mention that a not terminating RTP MCU will relay the RTCP, again I would think that it may cause too much RTCP traffic, again the right way is described in the next paragraph where the MCU handles the RTCP.

No. I don't agree. RTCP is self reacting. In fact I think it is wrong to 
terminate RTCP in the MCU. By terminating RTCP you loose functionality 
that would be available if you didn't terminate RTCP in the middle.

> 
> 5. Since section 3.6 discuss the "real" MCUs why do we need the other two in 3.3 and 3.5. At least the problem with those architectures should be clear.

The point of the draft is to discuss how different topologies affect the 
handling necessary. In fact my intention was to try to make people aware 
that implementing a 3.6 MCU is in fact in many case unnecessary complex 
and result in reduced functionality.

> 
> 6. In section 3.6 
> " In other words, the outgoing session typically uses a different SSRC, and may well use a different PT, even if this different PT happens to be mapped to the same media type.  (This is the definition of this topology and distinguishes it from the topologies previously discussed)."
> Isn't it true also for media translator described in 3.3 or mixer. Reading RFC 3550 section 7 it is clear that a translator may change the PT and timestamp but will keep the SSRC while a mixer will change also the SSRC like the MCU, the difference is that in the mixers the SSRCs of all participants will need to be part of the same space while in the MCU it is not clear, not using the same SSRC space in the MCU will not enable using the CSRC to list the contributing sources since they may be not unique. This may explain why in case b the MCU cannot use the CSRC.
> 
> 
I think you are taking the text out of the context. If you read the 
whole paragraph it should be clear it isn't only the different SSRC and 
PT that are of importance, it is the complete separation of the RTP 
session between each of the participants and the MCU.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 17 Jan 2007 14:32:00 +0100

Keith Lantz skrev:
> Indeed, I'm also confused by some of distinctions drawn between the 
> non-multicast topologies in Sections 3.3 through 3.6. In addition to 
> your points,  for example, the topology associated with Figure 5 sure 
> looks like a classic audio-only bridge or a video bridge that support 
> continuous presence -- belying the statement "this form of mixing 
> technology is not widely deployed".

If it is the judgment calls on how commonly things are used. Then we can 
remove them. However to me it has been extremely uncommon that anyone 
have implemented the RTP parts correct, even if the connection scenario 
looks the same. The big issues this draft tries to address is that the 
devil is in the details on how you handle RTP and that will affect the 
functionality.

> 
> Similarly, the distinctions between Topo-Video-switch-MCU (Section 3.5) 
> and Topo-RTCP-terminating-MCU (Section 3.6) are vague. For example, 
> Section 3.5 contains a paragraph that begins "If not terminating RTP 
> ...", suggesting that RTP termination is an option for that topology ... 
> but then it would terminate RTCP as well, thus reduce to 
> Topo-RTCP-terminating MCU, no? Then again, why is the focus of Section 
> 3.6 on RTCP (termination), rather than RTP (termination)?
> 

The main difference between 3.5 and 3.6 is if RTCP is terminated or not.
I can agree that the formulation that you point is somewhat unfortunate. 
I think what is missing is that RTP should be replaced with "the RTP 
media stream". Thus indicating the RTCP SR is forwarded for at least the 
media stream that is being sent to the receivers.

Cheers

Magnus Westerlund

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 17 Jan 2007 22:15:22 +0200

Magnus,
>From the email thread -

I think this is where I disagree. MCUs are implemented as in 3.6. The others are interesting but defiantly not common.
Terminating RTP enables the MCU to manage the flows. For voice activated video switch you need to mix the audio and also request fast update from the new speaker in order to make a smooth switch. People do not like a video switch that has artifacts.

Roni

---

From: Ladan Gharai <[email-masked]>
Date: Wed, 17 Jan 2007 18:43:07 -0500

On Jan 17, 2007, at 3:15 PM, Even, Roni wrote:

> Magnus,
>
>> From the email thread -
>>
>
> 5. Since section 3.6 discuss the "real" MCUs why do we need the  
> other two in 3.3 and 3.5. At least the problem with those  
> architectures should be clear.
>
> I think this is where I disagree. MCUs are implemented as in 3.6.  
> The others are interesting but defiantly not common.
> Terminating RTP enables the MCU to manage the flows. For voice  
> activated video switch you need to mix the audio and also request  
> fast update from the new speaker in order to make a smooth switch.  
> People do not like a video switch that has artifacts.

    I have read the draft and found it to be useful overall -  
particularly as it clarifies the the mixer and translator concepts as  
depicted in RFC 3550

    I am not sure it matters if the 3.3 to 3.5 are common or not?  
although perhaps the draft should avoid stating which topology is  
common.

   I do find though that the text is generally confusing on what the  
function of the topology is from a users perspective and how that  
function is achieved, i.e, shared SSRC, terminating  RTP? Perhaps a  
point by point comparison of the topologies would clarify the  
differences between them?

  Is the text about codec control messages meant to be in this draft  
or are they left over from the CCM draft?  If they are meant to be  
part of this draft a brief description would be helpful to the reader  
- also there is no discussion in 3.5 on how CCMs would be processed  
by that topology.

nit: figures 2 and 7 are missing directional arrows

Ladan

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 18 Jan 2007 11:32:56 +0100

> Terminating RTP enables the MCU to manage the flows. For voice activated video switch you need to mix the audio and also request fast update from the new speaker in order to make a smooth switch. P…
Roni,

My proposal is that we remove the qualifications on what is common etc 
and try to focus on what the difference is between the different 
concepts. We probably need to clean up how we use MCU in the text. To my 
understanding MCU would apply to both 3.5 and 3.6.

In regards to your voice activated video switching MCU. I would claim 
that you can implement that as an RFC 3550 MIXER without completely 
terminating RTCP. The RTP model does lose some functionality if you 
don't carry the joint SSRC space forward between the different mixing 
domains. That is why I would hope that the AVT WG in its WG document can 
make such recommendation. Do you disagree and think that AVT should 
recommend to mutilate its own design?

Cheers

Magnus Westerlund

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 18 Jan 2007 15:22:57 +0200

Magnus,
I think that an MCU is not a RFC3550 mixer like described in AVT.
You can implement a RFC3550 mixer but my point was that what I know as MCU is not a mixer but has higher layer application supplying information about the participants like SIP conference event package or H.243 (TCS and IIS) in H.323
Roni

________________________________

מאת: Magnus Westerlund [mailto:[email-masked]]
נשלח: ה 18/01/2007 12:32
אל: Even, Roni
עותק לידיעה: [email-masked]
נושא: Re: [AVT] Working group last call: draft-ietf-avt-topologies-03

Roni,

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 18 Jan 2007 15:44:35 +0100

> You can implement a RFC3550 mixer but my point was that what I know as MCU is not a mixer but has higher layer application supplying information about the participants like SIP conference event pac…

Okay,

My focus is on the RTP handling done by the MCU. For me it is obvious 
that an RTP mixer could take further input from the application layer to 
determine what type of mixing operation and how do it. Maybe yet another 
thing that we should clarify in the text.

Cheers

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Fri, 19 Jan 2007 13:43:38 +0000

> I think that an MCU is not a RFC3550 mixer like described in AVT.

Is that a feature, or a bug?

> You can implement a RFC3550 mixer but my point was that what I know  
> as MCU is not a mixer but has higher layer application supplying  
> information about the participants like SIP conference event  
> package or H.243 (TCS and IIS) in H.323

I don't see why that should preclude implementation of the RFC 3550  
mixer or translator model.

Colin

---

From: "Even, Roni" <[email-masked]>
Date: Sun, 21 Jan 2007 14:24:13 +0200

Colin,
It is a terminology point. The common MCU is not a mixer. The term MCU
is not related to a specific media format it was started as a circuit
switch entity.
You can implement a conference bridge using an RTP mixer but this is not
the common implementation.
So my point is that the use of common may be used with the section 3.6
example and not with 3.3 or 3.5
Roni

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Friday, January 19, 2007 3:44 PM
> To: Even, Roni
> Cc: Magnus Westerlund; [email-masked]
> Subject: Re: [AVT] Working group last call:
draft-ietf-avt-topologies-03

---

From: Colin Perkins <[email-masked]>
Date: Sun, 21 Jan 2007 13:33:33 +0000

Roni,

> is not related to a specific media format it was started as a circuit

I understand that. My point was that your statement that an MCU has a  
"higher later applications supplying information about the  
participants" does not preclude an MCU being implemented as an RTP  
mixer, whereas you implied that it had to be a distinct type of entity.

-- 
Colin Perkins
http://csperkins.org/