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

Stephan,
This can be as an early WGLC and make a revision after the second WGLC.
Roni

> -----Original Message-----
> From: Stephan Wenger [mailto:stewe@stewe.org]
> Sent: 01 December, 2014 12:44 AM
> To: avt@ietf.org; Liuyan (Scarlett); Roni Even
> Subject: 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-upd
> >>ate
> >>/
> >>
> >> There's also a htmlized version available at:
> >> http://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-0
> >> 5
> >>
> >> A diff from the previous version is available at:
> >>
> >>http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-topologies-upd
> >>ate
> >>-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