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

"Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com> Mon, 12 March 2012 11:46 UTC

Return-Path: <albrecht.schwarz@alcatel-lucent.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id EC6F621F875A; Mon, 12 Mar 2012 04:46:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.533
X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=1.562, BAYES_00=-2.599, FRT_BELOW2=2.154, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id eazRj-tDx1XZ; Mon, 12 Mar 2012 04:46:32 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr []) by ietfa.amsl.com (Postfix) with ESMTP id B640921F86EE; Mon, 12 Mar 2012 04:46:31 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com []) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q2CBisoR027386 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 12 Mar 2012 12:46:29 +0100
Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([]) with mapi; Mon, 12 Mar 2012 12:46:23 +0100
From: "Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com>
To: "'Jonathan Lennox'" <jonathan@vidyo.com>, "'IETF AVTCore WG'" <avt@ietf.org>
Date: Mon, 12 Mar 2012 12:46:22 +0100
Thread-Topic: RTPTOPO & H.248; RE: [AVTCORE] Fwd: I-D Action: draft-lennox-avtcore-rtp-topo-offer-answer-00.txt
Thread-Index: Acz+UKR6NWmv24w7TpinCrioOF59zABh5NzwABrCenA=
Message-ID: <5F7BCCF5541B7444830A2288ABBEBC9621626AD838@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com>
References: <20120305215535.22939.91509.idtracker@ietfa.amsl.com> <3A00EA94-E3D3-404A-8283-599D156481D8@vidyo.com> <4f5d300c.0755b40a.44ab.ffffc16a@mx.google.com>
In-Reply-To: <4f5d300c.0755b40a.44ab.ffffc16a@mx.google.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on
Cc: megaco <megaco@ietf.org>
Subject: [AVTCORE] RTPTOPO & H.248; RE: Fwd: I-D Action: draft-lennox-avtcore-rtp-topo-offer-answer-00.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2012 11:46:33 -0000

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.

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.


-----Original Message-----
From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] 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

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: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of
> Jonathan Lennox
> Sent: Saturday, March 10, 2012 1:59 AM
> 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: "internet-drafts@ietf.org" <internet-drafts@ietf.org>
> > Date: March 5, 2012 4:55:35 PM EST
> > To: "i-d-announce@ietf.org" <i-d-announce@ietf.org>
> > Subject: I-D Action: draft-lennox-avtcore-rtp-topo-offer-answer-
> 00.txt
> > Reply-To: "internet-drafts@ietf.org" <internet-drafts@ietf.org>
> >
> >
> > 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
> > I-D-Announce@ietf.org
> > 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
> jonathan@vidyo.com
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

Audio/Video Transport Core Maintenance