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

From: "Even, Roni" <[email-masked]>
Date: Fri, 8 Dec 2006 19:43:17 +0200

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

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 26 Dec 2006 15:12:31 +0200

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.

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. 

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?

Nits

1. In the abstract section disucsses should be "discusses"
2. In section 2.2 fulfil should be fulfill
3. In section 3.3 multicasted suggest changing to multicast
4. In section 3.3 " and the SSRC a field the translator should not change." I think that you meant "the SSRC is a ...."

5. In section 3.4 " However the mixer does only need one SSRC in each domain that is the receiving entity and transmitter of mixed content." I am not sure what this sentence is trying to say.

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 26 Dec 2006 16:09:59 +0200

Sorry, I sent the previous email too early.

Hi,

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.

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.

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.

Nits

6. In section 3.5 you have "behaviour" twice should be "behavior"

7. In section 3.6 you mention the SIP conference event package, suggest adding a reference.

8. In section 3.7 "uniquenss" change to "uniqueness"

---

From: Keith Lantz <[email-masked]>
Date: Fri, 29 Dec 2006 15:51:45 -0800

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".

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)?

Those and Roni's issues are the big questions. But since I marked it 
up while reading I might as well also pass on the nits now (with a 
modicum of effort *not* to be redundant with Roni's list):

- The document could probably use a more descriptive title -- perhaps 
"RTP Topologies for Multipoint Conferencing" (?), if the focus 
remains on multipoint conferencing.

- p. 1 & elsewhere: "<x> based" --> "<x>-based". (Similarly for "<x> 
specific", "<x> dependent", etc."

- p. 3: "lied" --> "lay"

- p. 4: "the models, see Section 3.7" --> "the models; see Section 
3.7" ... assuming, that is, that there's eventually going to be 
enough material in Section 3.7 to bother referring to. ;-)

- p. 5, end of Section 3.2: "session where" --> "sessions where"

         "as as" --> "as"

- p. 6: "that separates them" --> "that separate them"

         "trivial, for example ... IP addresses, and" --> "trivial -- 
for example, when Transport Translators just need to adjust IP addresses -- or"

- p. 7: "multicast capable" --> "multicast-capable"

- p. 8, first line: Insert comma after "in some cases".

         mid paragraph: Insert comma after "for example".

         last paragraph of Section 3.3: Delete comma after ")".

- p. 10, Section 3.5: "is, today, still deployed" --> "is still 
deployed today" ... assuming this sentence survives attempts to 
address the bigger issues noted above.

- p. 11, Section 3.5: "freely forward" --> "freely forwarded"

         Insert comma after "However".

         "results in that most participants see" --> "results in most 
participants seeing"

         "In consequence" --> "Consequently"

- pp. 12f, last paragraph: Delete comma following "RFC 3550 describes".

         "also deprive" --> "also deprives"

         "machine usable way. Thus" --> "machine-usable way, thus"

         "extend" --> "extent"

- p. 13, Section 3.7: "must, however, be taken" --> "must be taken, however".

         "is handled, mixers" --> "is handled. Mixers"

         "MCU, 3.5" --> "Topo-Video-switch-MCU" (again assuming that 
topology survives)

         "afterthought" --> "thought"

- pp. 13f, Section 3.8: "for example IP" --> "for example, IP"

         "However in general" --> "However, in general"

         "entity if subverted or misbehaving to" --> "entity, if 
subverted or misbehaving, to"

         ", see RFC 3550 and any applicable profiles," --> "-- see 
RFC 3550 and any applicable profiles --"

         "some implications as follows" --> "some implications"

         "First it might" --> "First, it might"

         I have no idea what you're trying to saying with 
"appropriate (which often translate in similar)".

         "participants, one example" --> "participants. One example"

         Remove comma after "group keys".

Happy New Year!

Keith

At 06:09 AM 12/26/2006, Even, Roni wrote:
>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.
>
>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.
>
>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?
>
>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.
>
>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.
>
>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.
>
>
>
>Nits
>
>4. In section 3.3 " and the SSRC a field the translator should not 
>change." I think that you meant "the SSRC is a ...."
>
>5. In section 3.4 " However the mixer does only need one SSRC in 
>each domain that is the receiving entity and transmitter of mixed 
>content." I am not sure what this sentence is trying to say.
>