Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-06

Colin Perkins <csp@csperkins.org> Wed, 09 April 2014 10:55 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C971A021E for <mmusic@ietfa.amsl.com>; Wed, 9 Apr 2014 03:55:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham
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 if3TeHncgIxN for <mmusic@ietfa.amsl.com>; Wed, 9 Apr 2014 03:55:25 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id D32641A01FA for <mmusic@ietf.org>; Wed, 9 Apr 2014 03:55:24 -0700 (PDT)
Received: from [130.209.247.112] (port=64847 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <csp@csperkins.org>) id 1WXqA1-0007Cb-Cc; Wed, 09 Apr 2014 11:55:22 +0100
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2AB260@ESESSMB209.ericsson.se>
Date: Wed, 9 Apr 2014 11:55:14 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <51F4517A-9FED-4880-9495-28A5A53192ED@csperkins.org>
References: <7594FB04B1934943A5C02806D1A2204B1D2AB260@ESESSMB209.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.1874)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/yMK1WEkHJYVRN-M--HVgUHY0r_g
Cc: "mmusic \(E-mail\)" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-06
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 09 Apr 2014 10:55:30 -0000

Christer,

Section 8.1.1 starts:

   By default, all RTP based media within a BUNDLE group belong to a
   single RTP session [RFC3550].  Multiple BUNDLE groups will form
   multiple RTP Sessions.

   NOTE: The usage of multiple RTP sessions within a BUNDLE group, or
   the usage of a single RTP session that spans over multiple BUNDLE
   groups, is outside the scope of this specification.  Other
   specification needs to extend the BUNDLE mechanism in order to allow
   such usages.

   When a single RTP session is used, all bundled "m=" lines
   representing RTP based media share a single SSRC numbering space
   [RFC3550].

I suggest rephrasing this as:

   All RTP-based media within a single BUNDLE group belong to a 
   single RTP session [RFC3550]. Multiple BUNDLE groups will form 
   multiple RTP sessions, one per bundle group.

   Since a single RTP session is used for each bundle group, all 
   “m=“ lines representing RTP-based media in a bundle group will 
   share a single SSRC numbering space [RFC3550].

Similarly, in the Introduction, I suggest changing:

   The default assumption is that all Real-Time Protocol (RTP) [RFC3550]
   based media flows associated with a BUNDLE group belong to the same
   RTP Session [RFC3550].  Future extensions can change that assumption.

to

   All Real-time Transport Protocol (RTP) [RFC3550] based media flows 
   associated with a single BUNDLE group belong to a single RTP session 
   [RFC3550].

The rationale for this change is that supporting multiple RTP sessions on a single 5-tuple is a significant change to RTP, for example to introduce a shim-layer, that did not receive consensus in AVTCORE. These changes align the bundle draft with that decision, and reword the text for clarity.

Colin


On 7 Apr 2014, at 09:06, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
> We have submitted a new version (-06) of BUNDLE.
>  
> As you will see, the document has been re-structured quite a bit. The main reason for that was to align the SDP offer/answer procedures with the RFC 3264 structure (I had to do that for another draft, so I decided to do the same thing also for BUNDLE – rather now than when we reach WGLC).
>  
> The draft does have a dependency on an RTP header indicator, and the completion of draft-ietf-mmusic-sdp-mux-attributes, but otherwise there are currently no BUNDLE specific open issues.
>  
> Regards,
>  
> Christer
>  
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic



-- 
Colin Perkins
http://csperkins.org/