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

From: [email-masked]
Date: Wed, 12 Nov 2014 12:06:49 -0800

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/

---

From: "Liuyan (Scarlett)" <[email-masked]>
Date: Thu, 20 Nov 2014 09:07:03 +0000

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. 

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.

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.
Therefore, the sentence "for SFMs the required functionality can be derived from that text. " should be removed or modified. 

Thanks.

Best Regards,
Scarlett

> -----Original Message-----
> From: avt [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Thursday, November 13, 2014 4:07 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-topologies-update-05.txt
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Stephan Wenger <[email-masked]>
Date: Sun, 30 Nov 2014 22:43:50 +0000

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)" <[email-masked]> wrote:

>	The RTP protocol includes functionality to identify the session
>participants through the use of the SSRC and CSRC fields.
>
>	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.

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

>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

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

---

From: "Roni Even" <[email-masked]>
Date: Mon, 1 Dec 2014 07:12:00 +0200

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

> From: Stephan Wenger [mailto:[email-masked]]
> Sent: 01 December, 2014 12:44 AM
> To: [email-masked]; Liuyan (Scarlett); Roni Even
> Subject: Re: [AVTCORE] I-D Action:
draft-ietf-avtcore-rtp-topologies-update-
> 05.txt
inline.
> to summarize, small clarifications appear to be in order.  Should I rev
the doc
> now, or take this as an early WGLC comment?
> 
> Stephan
> 
> >	RTP includes explicit specification text for Translators and Mixers,
> >and for SFMs the required functionality can be derived from that text.
> 
SSRC
> numbering space).  Therefore, what is required in the SFM is an
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.
> 
> >
> >
> >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.
> 
sessions
> per End Point² do not support RTP-based identification.  The
> >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.
> 
participants.
> because there is no single entity that has the full picture of what¹s
going on.
> With SFMs, that entity exists.
> 
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
> >
> >>https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-topologies-upd
> >>ate
> >>/
> >>
> >>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.
> >>
> >> Audio/Video Transport Core Maintenance [email-masked]