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

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Feb 2013 14:59:21 +0100

Hi Albert,

I am very sorry for the long time until I replied to this. It took a
long time until I started editing in comments and preparing a new
version of the draft.

Please see inline for my comments on your valuable comments.

On 2012-10-16 17:01, Schwarz, Albrecht (Albrecht) wrote:
> 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.

Based on your comments, I conclude that you desire a standards track
specification for the behavior for all RTP and RTCP fields including all
existing extensions how to process them in each topology.

>From my perspective, this document is not that document. It is an
important high level discussion tool, but it is not a specification for
how the behavior must be.

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

I don't think I can provide an definition of an RTP topology that is
more precise than:

A method for interconnecting RTP entities and its processing behavior of
RTP and RTCP is called an RTP topology.

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

I think doing what you suggest would take this document way beyond its
informational status into an RFC 3550 update with processing rules.

What I have done is an attempt to clarify what I consider as the
important aspects that needs to be discussed on a high level and which I
think reflects the aspects discussed in the comparisions:

- How it interconnect RTP/RTCP aware entities
- How RTP entities process the encoded media present in the RTP flows
- How it manages identity and visibility of any other RTP entities and
their media sources.

> 
> 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):

See 2)

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

I don't understand which problem you are bringing up. Is your problem
that middleboxes treats different extensions differently, for example
doesn't forward them?

I see RTP as a tool box, when building a service you actually have to
specify what expected behavior you want out of the system components,
and in the case of RTP, middleboxes also needs to be specified.

Yes, RTP might not provide the most clear tool specifications when it
comes to behavior so that you can point to it and say. I want this and
this behavior.

Yes, such updates could be done in the AVTCORE WG. However, it is not
this document. If you needs this I would recommend you to try to
determine interest for this and start up work on this.

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

This is having the Middlebox have two different RTP sessions. Then
function as an application gateway. I think this may be worth discussing
as it has some significant implications on the session.

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

I fail to see what is different for this topology compared to the
transport translator in the special case that it has only two single
end-points in the RTP session. If the middlebox in a point to point
scenario only rewrites the transport layer information this happens
without the RTP level really needs to be aware of it. This behavior is
common, and can be achieved using TURN servers, media anchoring SBG etc.

This was already present in Section 3.4.1, however I am looking at
pulling this out to a new sub-section for point to point with
middleboxes. That is also where I plan to add some discussion on B2B RTP
sessions.

Thanks

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 21 Feb 2013 14:28:11 +0100

On 2012-10-25 15:00, Roni Even wrote:
> 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). 

Ok, I will start adding, but I likely need reviewers to help hint where
it needs to be further discussed.

> 2. I did not fully understand the SSRC behavior for source projecting
> middlebox and how it is different from the topologies in 3.5.

I have tried to make clearer examples. However, I don't know which
aspect that you are uncertain about. The source projecting mixer will
expose all the other RTP media streams that the endpoint doesn't produce
themselves towards them. The SSRC values actually used may be remapped.
Then there can exist control logic that selects the RTP streams to
translate and transmit towards a given end-point.

Cheers

Magnus

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

-- 

Magnus Westerlund