Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-topologies-update-05.txt

Hi Scarlett,
Thanks for the careful reading of the draft.  Please see my comments
inline.

Hi Roni,
to summarize, small clarifications appear to be in order.  Should I rev
the doc now, or take this as an early WGLC comment?

Stephan

On 11/20/14, 01:07, "Liuyan (Scarlett)" <scarlett.liuyan@huawei.com> wrote:

>Hi Stephan,
>
>I have already the latest version and have a question.
>The section 4.5 says:
>	The RTP protocol includes functionality to identify the session
>participants through the use of the SSRC and CSRC fields.
>
>And the section 4.5 continues to say:
>	RTP includes explicit specification text for Translators and Mixers, and
>for SFMs the required functionality can be derived from that text.

This statement has to be read broadly.  In particular, in SFMs, the CSRC
mechanism doesn¹t work directly as specified in RFC 3550, because each End
Point connects to the SFM using its own RTP session (each having its own
SSRC numbering space).  Therefore, what is required in the SFM is an
(unspecified) mapping mechanism that maps the local SSRC values between
between the RTP session.  In other words, End Points do see CSRC values,
but the value of the CSRC value for a given contributing endpoint may be
different for each receiving End Point, and different from the SSRC of the
sending End Point.  See page 30, 2nd paragraph.

> 
>
>At last the section says:
>	The topologies that create independent RTP sessions per End point or
>pair of End points, like back-to-back RTP session, MESH with independent
>RTP sessions, and the RTCP terminating MCU RTCP terminating MCU do not
>support RTP based identification of session participants.

... and SFMs do.  Even if they are RTCP terminating topologies.
Conclusion: most, but not all topologies that ³create independent RTP
sessions per End Point² do not support RTP-based identification.  The
exception are SFMs.   A clarifying sentence seems in order.

>
>It seems to inconsistent on SFMs.
>Based on the section 3.7, SFM: all potential RTP sources into a
>per-endpoint, independent RTP session.
>I think that SFMs have a similar behavior with MESH with independent RTP
>sessions, and then do not support RTP based identification of session
>participants.

That¹s incorrect.  SFMs support RTP-based identification of session
participants.

With MESH, one cannot easily map the different SSRC spaces to each other,
because there is no single entity that has the full picture of what¹s
going on. With SFMs, that entity exists.

>Therefore, the sentence "for SFMs the required functionality can be
>derived from that text. " should be removed or modified.

I would agree that this sentence may be a bit misleading if read in
isolation, as the required cross-RTP session mapping mechanism (page 30,
2nd paragraph) cannot be directly read from RFC 3550.  At least I do not
recall out of hand a section in RFC 3550 that contemplates this issue.  I
could easily add a back-reference to 3.7, and mention that there is an
SSRC number mapping mechanism required.  Would that clarify the issue?

Thanks,
Stephan

> 
>
>Thanks.
>
>Best Regards,
>Scarlett
>
>> -----Original Message-----
>> From: avt [mailto:avt-bounces@ietf.org] On Behalf Of
>> internet-drafts@ietf.org
>> Sent: Thursday, November 13, 2014 4:07 AM
>> To: i-d-announce@ietf.org
>> Cc: avt@ietf.org
>> Subject: [AVTCORE] I-D Action:
>>draft-ietf-avtcore-rtp-topologies-update-05.txt
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>>directories.
>>  This draft is a work item of the Audio/Video Transport Core Maintenance
>> Working Group of the IETF.
>> 
>>         Title           : RTP Topologies
>>         Authors         : Magnus Westerlund
>>                           Stephan Wenger
>> 	Filename        : draft-ietf-avtcore-rtp-topologies-update-05.txt
>> 	Pages           : 46
>> 	Date            : 2014-11-12
>> 
>> Abstract:
>>    This document discusses point to point and multi-endpoint topologies
>>    used in Real-time Transport Protocol (RTP)-based environments.  In
>>    particular, centralized topologies commonly employed in the video
>>    conferencing industry are mapped to the RTP terminology.
>> 
>>    This document is updated with additional topologies and is intended
>>    to replace RFC 5117.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> 
>>https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-topologies-update
>>/
>> 
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-05
>> 
>> A diff from the previous version is available at:
>> 
>>http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-topologies-update
>>-05
>> 
>> 
>> Please note that it may take a couple of minutes from the time of
>>submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> avt@ietf.org
>> https://www.ietf.org/mailman/listinfo/avt