[AVTCORE] RTPTOPO & H.248; RE: Fwd: I-D Action: draft-lennox-avtcore-rtp-topo-offer-answer-00.txt

["Schwarz, Albrecht (Albrecht)" <[e-mail]>]

Hello Jonathan,

like to open a separate email thread (because not related to Roni's comments):

Scope of your draft is related to RTP TOPO considerations, complemented by SDP O/A exchange. 
Like to note that this subject is also addressed by ITU-T SG16 Q.3 for "RTP topology functions" located in decomposed gateways according H.248.
The work item is called
H.248.RTPTOPO "RTP topology dependent RTCP handling by H.248 Media Gateways with IP Terminations"

You may find a draft document under e.g.
http://wftp3.itu.int/av-arch/avc-site/2009-2012/1202_Gen/AVD-4162.zip 

There are some overlappings between your considerations and H.248.RTPTOPO, primarily on "topology awareness", "topology configuration/control".

H.248.RTPTOPO considers all your four indicated RTP topologies.
The SDP O/A procedures are processed by the H.248 Media Gateway Controller (MGC). The RTP functions are embedded in the H.248 Media Gateway.

Appendix I provides some initial ideas how the RTP topology could be controlled via H.248 ("possibly triggered by SDP O/A").

Appendix II indicates also the correlation between SRTP vs RTP topologies.

Regards,
Albrecht


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Roni Even
Sent: Montag, 12. März 2012 00:06
To: 'Jonathan Lennox'; 'IETF AVTCore WG'
Subject: Re: [AVTCORE] Fwd: I-D Action: draft-lennox-avtcore-rtp-topo-offer-answer-00.txt

Hi Jonathan,
I read the draft and I assume you are talking about a relay architecture
without signaling, is this the case, is it only for point to point?
If the Topo-Transport-Translator need also to relay to multiple parties you
need also for SRTP to discuss the key distribution and synchronization since
not all parties join at the same time. This is discussed in
drafty-ietf-avt-srtp-ekt.

As for the offer answer discussion in section 4 the central box can enforce
a single view which it calls the common mode. The participants who cannot
support this common mode are second class participants. The assumption is
that there will be at least a common audio mode (used to be G.711) or in
RTCWeb the mandatory audio codec so second class participants will have the
audio connection. The assumption is that most of the parameters you
specified in section 4 are not fixed values but maximum values and any value
bellow it is also supported.

I think that another issue that should be discussed in the topo-offer-answer
is how the offer size scales if there are multiple streams and if the SSRC
attribute is used to distribute the list of all participants for source
selection. You have some information in
draft-lennox-mmusic-sdp-source-selection but it does not discuss the issue
of the offer size. 

Roni Even 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Jonathan Lennox
> Sent: Saturday, March 10, 2012 1:59 AM
> To: IETF AVTCore WG
> Subject: [AVTCORE] Fwd: I-D Action: draft-lennox-avtcore-rtp-topo-
> offer-answer-00.txt
> 
> Hi, all -- I've submitted this draft discussing the interaction of SDP
> Offer/Answer with RTP topologies -- specifically, why the RTP topology
> Topo-Transport-Translator can't be created with offer/answer, and why
> this is actually a good thing.
> 
> This is a generalization of a some issues that came up in the
> discussion of BUNDLE in Taipei.
> 
> Comments are welcome.
> 
> Begin forwarded message:
> 
> > From: "[e-mail]" <[e-mail]>
> > Date: March 5, 2012 4:55:35 PM EST
> > To: "[e-mail]" <[e-mail]>
> > Subject: I-D Action: draft-lennox-avtcore-rtp-topo-offer-answer-
> 00.txt
> > Reply-To: "[e-mail]" <[e-mail]>
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >
> > 	Title           : Real-Time Transport Protocol (RTP) Topology
> Considerations for Offer/ Answer-Initiated Sessions.
> > 	Author(s)       : Jonathan Lennox
> > 	Filename        : draft-lennox-avtcore-rtp-topo-offer-answer-
> 00.txt
> > 	Pages           : 11
> > 	Date            : 2012-03-05
> >
> >   This document discusses a number of considerations related to the
> >   topologies of Real-Time Transport Protocol (RTP) sessions initated
> >   using the Session Description (SDP) unicast Offer/Answer Model,
> >   especially as applied to source-multiplexed sessions.
> >
> >   The primary observation is that certain topologies cannot be
> created
> >   by unicast SDP Offer/Answer.  Notably, the it is not possible to
> >   negotiate the topology that RFC 5117 calls Topo-Transport-
> Translator
> >   (or "relay").
> >
> >   As a consequence of this limitation, certain topological
> assumptions
> >   can safely be made for RTP sessions initiated using unicast SDP
> >   Offer/Answer; and therefore, certain optimizations to RTP are
> >   possible in such sessions.  This document also describes the
> >   optimizations that these assumptions make possible.
> >
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-lennox-avtcore-rtp-topo-
> offe
> > r-answer-00.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > This Internet-Draft can be retrieved at:
> > ftp://ftp.ietf.org/internet-drafts/draft-lennox-avtcore-rtp-topo-
> offer
> > -answer-00.txt
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > [e-mail]
> > 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
> >
> 
> --
> Jonathan Lennox
> [e-mail]
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Core Maintenance
[e-mail]
https://www.ietf.org/mailman/listinfo/avt