Subject: [AVT] I-D Action:draft-ietf-avt-topologies-05.txt

From: [email-masked]
Date: Fri, 06 Jul 2007 11:30:02 -0400

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-05.txt
        Pages           : 21
        Date            : 2007-07-06
                                                                                           
This document discucsses multi-endpoint topologies 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-05.txt
                                                                                           
To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
        "get draft-ietf-avt-topologies-05.txt".
                                                                                           
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.
                                                                                           
Send a message to:
        [email-masked].
In the body type:
        "FILE /internet-drafts/draft-ietf-avt-topologies-05.txt".
                                                                                           
NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

---

From: Keith Lantz <[email-masked]>
Date: Fri, 06 Jul 2007 16:45:42 -0700

As with draft-ietf-avt-avpf-ccm, my compliments on having 
accommodated everyone's comments on previous drafts -- including 
addressing the various concerns about which topologies were more "common".

Some remaining/additional nits, though:

- Abstract: "discucsses" --> "discusses"

         "RTP based" --> "RTP-based"

- Section 1, first paragraph: "Messages [CCM], a considerable 
confusion was noticed in the community, with respect to" -->
         "Messages [CCM] considerable confusion was noticed in the 
community with respect to"

         2nd paragraph: Remove the comma from "was developed, the 
main emphasis".

- Section 3: First, I don't quite understand what you're trying to 
say with "and no direct RTP or RTCP SSRC related information is 
forwarded to the other participants". What do you mean by "direct"? 
What do you mean by "RTCP SSRC related information"?

         Also, the cross-reference to Section 3.7 should now be to Section 3.8.

- Section 3.3: Remove the commas following "(to bridge different 
domains)" and "Of the transport translators".

         "non-RTP based media transport, one crucial factor consists in"
         --> "non-RTP-based media transport one crucial factor is"

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

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

         Remove comma following "requests a bandwidth reduction".

- Section 3.4, p. 9, bottom: "generate sender report" --> "generate 
sender reports"

         p. 10, first sentence: Replace the semi-colon with a colon.

         2nd paragraph: "simplesr to implement and avoid" --> 
"simpler to implement and avoids"

- Section 3.5: "bit-rate, encoding, or resolution, however it" --> 
"bit-rate, encoding or resolution. However, it"

         bottom of p. 11: "at any given time, often"
         --> "at any given time -- often"

         p. 12: "two aspects. First it" --> "two features. First, it"
                 "The second is" --> "Second, the MCU needs"
                 "one implements" --> "one implement"

- Section 3.6, enumerated list: Lower-case the leading "A" and "The".

         following paragraph: Remove the comma following "different 
SSRC", and "is negotiated individually" --> "being negotiated independently".

         penultimate paragraph, on p. 13: "contributing sources, for 
example a" --> "contributing sources -- for example, a"

- Section 3.7, first paragraph: Lots of glitches here. Replace in its 
entirety with:

         "It is theoretically possible to construct an MCU that is a 
mixer in one direction and a translator in another. The main reason 
to consider this would be to allow topologies similar to Figure 5, 
where the mixer does not need to mix in the direction from B or D 
towards the multicast domains with A and C. Instead, the media 
streams from B and D are forwarded without changes. Avoiding this 
mixing would save media processing resources that perform the mixing 
in cases where it isn't needed. However, there would still be a need 
to mix B's stream towards D. Only in the direction B -> multicast 
domain or D -> multicast domain would it be possible to work as a 
translator. In all other directions it would function as a mixer."

         next paragraph: "Thus any" --> "Thus, any"

         next paragraph: "topologny" --> "topology"

- Section 3.8: Another bunch of small glitches. Replace in its entirety with:

         "Topologies can be combined and linked to each other using 
mixers or translators. However, care must be taken in handling the 
SSRC/CSRC space. A mixer will not forward RTCP from sources in other 
domains, but will instead generate its own RTCP packets for each 
domain it mixes into, including the necessary SDES information for 
both the CSRCs and the SSRCs. Thus, in a mixed domain the only SSRCs 
seen will be the ones present in the domain, while there can be CSRCs 
from all the domains connected together with a combination of mixers 
and translators. The combined SSRC and CSRC space is common over any 
translator or mixer. This is important to facilitate loop detection 
-- something that is likely to be even more important in combined 
topologies due to the mixed behavior between the domains. Any hybrid, 
like the Topo-Video-switch-MCU or Topo-Asymmetric, requires 
considerable thought on how RTCP is dealt with."

- Section 4.1, heading: "Proporties" --> "Properties"

- Section 4.1.1, 2nd paragraph: Insert comma after "IP-multicast-based".

         3rd paragraph: Insert comma after "Otherwise".
                 "Receiver Reports" --> "Receiver Reports"

- Section 4.1.2: "RTCP terminating" --> "RTCP-terminating"

- Section 4.1.4: "in that not even a minimal acceptable media quality 
is accomplished"
         --> "in a situation where even a minimal acceptable media 
quality cannot be accomplished"

- Section 4.1.5: "The MCUs described in Section 3.5" --> "The MCU 
described in Section 3.5"

- Section 5, p. 19: "wherein N is the total of number of SSRCs part 
of the joint SSRC space over all domains, and"
         --> "where N is the total number of SSRCs used over all domains and"

Regards, Keith

At 08:30 AM 7/6/2007, [email-masked] wrote:
>ENCODING mime
>FILE /internet-drafts/draft-ietf-avt-topologies-05.txt
> 
>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 09 Jul 2007 09:52:03 +0200

Hi,

Thanks to Keith for his review on the new version.

All other please take a look on the new section 3.7 that discusses 
non-symmetric mixer/translators. This was an result of comments from 
Geoff Hunt. I am going to address Keith's comments and submit updates 
when the submission opens again. So if you have any more comments please 
provide me with them before the meeting.

A diff from the previous version:
http://tools.ietf.org/wg/avt/draft-ietf-avt-topologies/draft-ietf-avt-topologies-05-from-04.diff.html

Cheers

Magnus

[email-masked] skrev:
> ------------------------------------------------------------------------
> 

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
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, 25 Jul 2007 19:21:03 +0200

Hi,

Thanks once more for these comments. We have incorporaed them into a 
version we intended to submit soon.

Cheers

Magnus Westerlund