Re: [MMUSIC] 3GPP RTP header extension
"Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com> Mon, 03 June 2013 08:12 UTC
Return-Path: <albrecht.schwarz@alcatel-lucent.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256B921F935A; Mon, 3 Jun 2013 01:12:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBF0zWsSFp9l; Mon, 3 Jun 2013 01:12:32 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id BD93B21F92F5; Mon, 3 Jun 2013 01:11:15 -0700 (PDT)
Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r538AQDm021293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Jun 2013 03:10:26 -0500 (CDT)
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r538AHwO017294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 04:10:26 -0400
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 3 Jun 2013 04:10:22 -0400
Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.41]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 3 Jun 2013 10:10:10 +0200
From: "Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: 3GPP RTP header extension
Thread-Index: Ac5YY467f6iD3KE+RZKtUYPDcgGk6wHzLKGw
Date: Mon, 03 Jun 2013 08:10:10 +0000
Message-ID: <786615F3A85DF44AA2A76164A71FE1AC046CF5@FR711WXCHMBA03.zeu.alcatel-lucent.com>
References: <7594FB04B1934943A5C02806D1A2204B1C377766@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C377766@ESESSMB209.ericsson.se>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.40]
Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC046CF5FR711WXCHMBA03zeu_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Cc: "megaco@ietf.org" <megaco@ietf.org>, "3GPP_TSG_CT_WG4@LIST.ETSI.ORG" <3GPP_TSG_CT_WG4@LIST.ETSI.ORG>
Subject: Re: [MMUSIC] 3GPP RTP header extension
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Jun 2013 08:13:09 -0000
The subject was also on the agenda of 3GPP CT4 at last meeting. It may be noted that RFC 5285 is special with regards to the definition of two capabilities of a) IP data path (RTP header extension; clause 4/RFC 5285) and b) IP signaling path (SDP signalling; ; clauses 5&6/RFC 5285) in a single RFC. Both capabilities could be also defined in separated RFCs. The tight coupling of both capabilities in a single RFC may be interpreted in the following: the network should not forward RTP packets with extended headers in case of missing SDP "a=extmap:" signalling or/and failed SDP O/A. E.g., an interim RTP translator (RTP transport translator or RTP media translator) would block RTP packets with extension headers (dependent on above SDP O/A ...). Conclusion: there seems to be some implicit semantics in RFC 5285 in my understanding. Regards, Albrecht From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Freitag, 24. Mai 2013 12:06 To: mmusic@ietf.org Subject: [MMUSIC] 3GPP RTP header extension Hi, In the virtual interim meeting yesterday, I was requested to look into the RTP header extension(s) defined by 3GPP. 3GPP SA4 has defined a header extension for "Coordination of Video Orientation" purpose (may be of interest for CLUE btw, but that's a separate story). The length of the extension is 1 byte. For more information, see section 7.4.5 of 3GPP TS 24.114 :) http://www.3gpp.org/ftp/Specs/archive/26_series/26.114/26114-c10.zip Regards, Christer
- [MMUSIC] 3GPP RTP header extension Christer Holmberg
- Re: [MMUSIC] 3GPP RTP header extension Schwarz, Albrecht (Albrecht)