Subject: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore-rtp-topologies-update-01.txt

From: Magnus Westerlund <[email-masked]>
Date: Mon, 15 Oct 2012 16:23:56 +0200

WG,

As individual

We have submitted two versions of this draft. The 00 is an XML2RFC
generated version from the text present in RFC 5117. The 01 version is a
first update. This focus on the RTP topologies present in the draft. The
text is kind of rough, so I would suggest that you focus on the questions:

- Are this the topologies the document should describe? Missing,
redundant etc.
- What do you think a topology discussion should contain. There will be
variations over the different topologies in this document.

Cheers

Magnus Westerlund

Subject: I-D Action: draft-westerlund-avtcore-rtp-topologies-update-01.txt
From: <[email-masked]>
To: <[email-masked]>
Date: Mon, 15 Oct 2012 07:20:26 -0700
List-Id: Internet Draft Announcements only <i-d-announce.ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : RTP Topologies
	Author(s)       : Magnus Westerlund
                          Stephan Wenger
	Filename        : draft-westerlund-avtcore-rtp-topologies-update-01.txt
	Pages           : 33
	Date            : 2012-10-15

Abstract:
   This document discusses 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 are intended
   to replace RFC 5117.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-westerlund-avtcore-rtp-topologies-update

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-topologies-update-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-westerlund-avtcore-rtp-topologies-update-01

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Tue, 16 Oct 2012 17:01:58 +0200

Dear All!

RFC 5117 was already a good progress wrt RFC 1889/3550, but is still at some areas too high-level in my opinion.
Thus, I support any update activity of RFC 5117.

BTW: this was also recently discussed in ITU-T SG16 Q3; there's a work item on "RTP topology dependent RTCP handling by H.248 Media Gateways with IP Terminations", called H.248.RTPTOPO.
The latest draft may be downloaded via 
http://wftp3.itu.int/av-arch/avc-site/2009-2012/1209_Bri/TD-21.zip 

Concerning
> - What do you think a topology discussion should contain. There will be variations over the different topologies in this document.

1) Terminology
What's still missing is an explicit definition for "RTP topology". Should be added in section 2.
The definition should answer the question "what constitutes exactly an RTP topology"?
There are different interpretations, such as "number and type of media interfaces" towards a characterization of an RTP topology based on the six properties of section 4.1.
But even such properties should be made more precise in my opinion.

2) RTP topology dependent RTP media packet handling
Comprehensive summary 
- which RTP header elements may or may not be modified under a particular RTP topology
- whether RTP payload may or may not be modified under a particular RTP topology

3) RTP topology dependent RTCP packet handling
Comprehensive summary 
- which RTCP elements may or may not be modified under a particular RTP topology
The existing text provides partial information, sometimes too high level.
It's also fairly difficult or even impossible to consider all possible RTCP information types under a particular topology, leading to (4):

4) Introduction of an RTCP service concept
Well known problem: a RTP transport translator shall be also used as measurement and reporting point of RTCP XR type of performance metrics. => Contradiction: different handling of RTCP basic and extension reports, SSRC usage, ...:-(
Possible solution: define different levels of RTCP services, such as
a) basic RTCP service (given by RFC 3550 core protocol)
b) RTP profile dependent RTCP service (given by RTP profile specification) and
c) supplementary RTCP service (such as RFC 3611, 5760, 6051, ...)

Above problem could be then solved by coupling (a) and (b) type of RTCP services with the RTP topology, and consider (c) as "overlay" (and topology independent).
See also Draft H.248.RTPTOPO.

5) Missing RTP topologies
There are two further topologies, which we've observed in middle boxes, SBCs, H.323 gateways, H.248 IP-IP gateways, but missing in RFC 5117:

a) Back-to-Back RTP Endsystem (B2BRE): e.g. a topology within the end-to-end path of the PtP topology. Please note that clause 3.1 does not describe the B2BRE topology.
E.g., RTP end-to-end path between A - MB - B (with MB as middle box)
 A  = RTP topology "RTP endsystem" (RFC 3550 notation; now perhaps "endpoint")
 B  = ditto
 MB = RTP topology "B2BRE"

The MP separates the e2e RTP network in two domains, e.g. a separation of the SSRC space.

b) Topology "transparent forwarding"
e.g. required for SRTP-to-SRTP forwarding
see definition in H.248.RTPTOPO

Just some initial thoughts,
Albrecht

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Montag, 15. Oktober 2012 16:24
To: IETF AVTCore WG
Subject: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore-rtp-topologies-update-01.txt

WG,

As individual

We have submitted two versions of this draft. The 00 is an XML2RFC generated version from the text present in RFC 5117. The 01 version is a first update. This focus on the RTP topologies present in the draft. The text is kind of rough, so I would suggest that you focus on the questions:

- Are this the topologies the document should describe? Missing, redundant etc.
- What do you think a topology discussion should contain. There will be variations over the different topologies in this document.

Cheers

Magnus Westerlund

---

From: "Roni Even" <[email-masked]>
Date: Thu, 25 Oct 2012 15:00:07 +0200

Hi Magnus,
I read the draft so to answer the questions

1. I think the document need also to discuss the SDES behavior (CNAME must
be forwarded to support the CSRC) specified in 7.2 and 7.3 of RFC 3550 for
the different topologies (we had recently a discussion about using SDES
messages). 
2. I did not fully understand the SSRC behavior for source projecting
middlebox and how it is different from the topologies in 3.5.

In general the document is good starting point, the SSRC issues are
discussed but need more review. 
I have some other comments but they are more topology specific.

Roni Even
As individual

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus
Westerlund
Sent: 15 October, 2012 4:24 PM
To: IETF AVTCore WG
Subject: [AVTCORE] Fwd: I-D Action:
draft-westerlund-avtcore-rtp-topologies-update-01.txt

WG,

As individual

We have submitted two versions of this draft. The 00 is an XML2RFC generated
version from the text present in RFC 5117. The 01 version is a first update.
This focus on the RTP topologies present in the draft. The text is kind of
rough, so I would suggest that you focus on the questions:

- Are this the topologies the document should describe? Missing, redundant
etc.
- What do you think a topology discussion should contain. There will be
variations over the different topologies in this document.

Cheers

Magnus Westerlund