From nobody Thu Jun 9 06:27:49 2016 Return-Path: X-Original-To: sandbox-mailoutput@ietfa.amsl.com Delivered-To: sandbox-mailoutput@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61CE12D0A9 for ; Thu, 9 Jun 2016 06:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 aR6y-2RpCelV for ; Thu, 9 Jun 2016 06:27:46 -0700 (PDT) Received: from sandbox.amsl.com (unknown [IPv6:2607:f170:8000:1500::d2]) by ietfa.amsl.com (Postfix) with ESMTP id 5E21012D63A for ; Thu, 9 Jun 2016 06:27:46 -0700 (PDT) Received: from sandbox.amsl.com (localhost [IPv6:::1]) by sandbox.amsl.com (Postfix) with ESMTP id 1E7FD1C3C77 for ; Thu, 9 Jun 2016 06:27:46 -0700 (PDT) Content-Type: multipart/mixed; boundary="===============2150870650025113216==" MIME-Version: 1.0 From: IETF Secretariat To: sandbox-mailoutput@ietf.org Message-ID: <20160609132746.21679.10000.idtracker@sandbox.amsl.com> Date: Thu, 09 Jun 2016 06:27:46 -0700 Archived-At: Subject: [Sandbox-mailoutput] [Django development] New Liaison Statement, "Response to Liaison Statement to IETF MMUSIC concerning 'Improved end-to-end QoS Enhancements for MTSI'" X-BeenThere: sandbox-mailoutput@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 13:27:47 -0000 --===============2150870650025113216== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The attached message would have been sent, but the tracker is in development mode. It was not sent to anybody. In addition to the destinations derived from the header below, the message would have been sent Bcc to statements@ietf.org --===============2150870650025113216== Content-Type: message/rfc822 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liaison Statement Management Tool To: , <3GPPLiaison@etsi.org> Cc: "Multiparty Multimedia Session Control Discussion List" , "Bo Burman" , "Alexey Melnikov" , "Flemming Andreasen" , "Alissa Cooper" , "Ben Campbell" Subject: New Liaison Statement, "Response to Liaison Statement to IETF MMUSIC concerning 'Improved end-to-end QoS Enhancements for MTSI'" X-Test-IDTracker: yes X-IETF-IDTracker: 6.21.1.dev0 Auto-Submitted: auto-generated Precedence: bulk X-Tracker-Bcc: statements@ietf.org Message-ID: <20160609132745.21679.21120.idtracker@sandbox.amsl.com> Date: Thu, 09 Jun 2016 06:27:46 -0700 Title: Response to Liaison Statement to IETF MMUSIC concerning 'Improved end-to-end QoS Enhancements for MTSI' Submission Date: 2016-06-09 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1481/ From: "Bo Burman" To: georg.mayer.huawei@gmx.com,3GPPLiaison@etsi.org Cc: Flemming Andreasen ,Ben Campbell ,Alissa Cooper ,Bo Burman ,Alexey Melnikov ,Multiparty Multimedia Session Control Discussion List , Response Contacts: Flemming Andreasen ,Bo Burman Technical Contacts: Purpose: In response Referenced liaison: LS on Improved end-to-end QoS Enhancements for MTSI (https://datatracker.ietf.org/liaison/1442/) Body: IETF MMUSIC Working Group thanks 3GPP TSG SA WG4 for informing about their work in . It is understandable that SDP attribute-based approaches, such as solutions D and F in 3GPP TR 26.924, are being considered for further development. Of the alternatives proposed, 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 TR 26.924. 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 i each "m=" line represents a single media sent on a single port, with the SDP 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. IETF MMUSIC urges 3GPP TSG SA4 to consider the impact of the SDP 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. Next IETF meetings: - IETF 96 July 17-22, 2016, Berlin, Germany - IETF 97 November 13-18, 2016, Seoul, South Korea Regards, Bo Burman MMUSIC WG co-chair Attachments: No document has been attached --===============2150870650025113216==--