Re: [MMUSIC] 3GPP liaison statement to IETF MMUSIC

Colin Perkins <csp@csperkins.org> Thu, 12 May 2016 17:01 UTC

Return-Path: <csp@csperkins.org>
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 4A57412D606 for <mmusic@ietfa.amsl.com>; Thu, 12 May 2016 10:01:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhCj7Wwu5RQD for <mmusic@ietfa.amsl.com>; Thu, 12 May 2016 10:01:47 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13A7712B04D for <mmusic@ietf.org>; Thu, 12 May 2016 10:01:47 -0700 (PDT)
Received: from [193.43.158.229] (port=60763 helo=[10.242.220.33]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <csp@csperkins.org>) id 1b0tzc-0007aY-94; Thu, 12 May 2016 18:01:45 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <7732AC53-DCF8-4FD1-9EA2-0CB27FA3A6A2@nostrum.com>
Date: Thu, 12 May 2016 19:01:38 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <B7BDC47B-D091-402C-9148-7F83CD0227B2@csperkins.org>
References: <BBE9739C2C302046BD34B42713A1E2A22E874B3B@ESESSMB105.ericsson.se> <7732AC53-DCF8-4FD1-9EA2-0CB27FA3A6A2@nostrum.com>
To: Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.3124)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/yj9UnOVqdqM-D8037JnWvx3E65k>
Cc: mmusic <mmusic@ietf.org>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Subject: Re: [MMUSIC] 3GPP liaison statement to IETF MMUSIC
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 12 May 2016 17:01:49 -0000

Bo, Ben,

I’ve revised this liaison statement, and the attached 3GPP TR 26.924 V13.0.0, at the chair’s request. I do not follow the work in 3GPP closely, but I understand that SDP attribute-based approaches, such as solutions D and F in the TR, are being considered for further development. 

Of the alternatives proposed, I believe that use of an SDP attribute (i.e., an “a=” line) is to be preferred over use of further extensions to SDP “b=“ lines. Attributes are the natural extension point for SDP, and offer flexibility that is not present in “b=“ lines. This is compatible with the solutions proposed by 3GPP.

Whether any new attribute is signalled per RTP payload type, as in solution D, or per m= line, as in solution F, is a more complex issue. Neither seems unreasonable on the surface, and a QoS attribute per “m=“ line is natural if each “m=“ line represents a single media sent on a single port, with the offer/answer exchange being used only to select what encoding is used for that media. 

However, with the definition and widespread adoption of the SDP BUNDLE extension, the assumption that a single “m=“ line represents a single type of media being sent on a single UDP port is becoming less tenable. I would urge 3GPP to consider the impact of the BUNDLE extension on their choice, and to further coordinate with IETF to ensure that whatever is developed is compatible with SDP sessions where multiple “m=“ lines, representing several different types of media, are sent on a single UDP port. 

Colin



> On 1 Dec 2015, at 21:25, Ben Campbell <ben@nostrum.com> wrote:
> 
> Does anyone have thoughts on this?
> 
> Thanks!
> 
> Ben.
> 
> On 16 Nov 2015, at 4:26, Bo Burman wrote:
> 
>> MMUSIC members,
>> 
>> We have received a liaison statement from the 3GPP TSG SA WG4 group.
>> 
>> Briefly summarizing the attached document, they have been studying resource allocation at session setup and have found lack of bandwidth information elements and lack of end-to-end alignment that can result in inconsistent setting of QoS parameters in 3GPP networks. They have also documented the problem analysis and potential solutions in a (publicly accessible) technical report.
>> 
>> They would like MMUSIC to consider their work and want us to provide feedback on whether we would like to be involved in the coordination of future work on this topic.
>> 
>> For details, please see the attached liaison document.
>> 
>> Cheers,
>> /Bo
>> 
>> ________________________________
>> 
>> Title:                      LS on Improved end-to-end QoS Enhancements for MTSI
>> 
>> Release:               Release 13
>> 
>> Work Item:         QOSE2EMTSI
>> 
>> Source:                 3GPP TSG SA WG4
>> 
>> To:                          IETF MMUSIC
>> 
>> Cc:                          3GPP TSG CT WG1, 3GPP TSG CT WG3, 3GPP TSG CT WG4
>> 
>> 
>> 
>> -------------------------------------------------------------
>> 
>> Susanna Kooistra, ETSI MCC
>> 
>> 3GPP liaison co-ordinator
>> 
>> E-mail: 3GPPLiaison@etsi.org<mailto:3GPPLiaison@etsi.org> <mailto:3GPPLiaison@etsi.org>
>> 
>> Please consider the environmental impact before printing this e-mail
>> 
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic