Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-12.txt

Suhas Nandakumar <suhasietf@gmail.com> Fri, 22 January 2016 04:33 UTC

Return-Path: <suhasietf@gmail.com>
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 31A771B37EA for <mmusic@ietfa.amsl.com>; Thu, 21 Jan 2016 20:33:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=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 mXS01EstiobA for <mmusic@ietfa.amsl.com>; Thu, 21 Jan 2016 20:33:34 -0800 (PST)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F5F01B37EB for <mmusic@ietf.org>; Thu, 21 Jan 2016 20:33:34 -0800 (PST)
Received: by mail-vk0-x229.google.com with SMTP id e185so35204999vkb.1 for <mmusic@ietf.org>; Thu, 21 Jan 2016 20:33:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a5Ddk2CZsypavy/NjZcPdSyGrnNPtgn1+uVKcCvRdr0=; b=tLL6RUhbavKdSXP2vZCcM1pnYLSMMrL2rA4du1VJyIrom9YhrztOVcEpgKlUbzKafH Ku4MLXXRJREIHVGtFra/WLCUZWcyoWvt38uf9Gmj5/ZHSIURJ5KpQKKimg/9c58NP4V6 vX/h4gvZVGYiy+VuKWJLpj7VjymxVkDBCPn7ODd4n+cT+6fVqbg8hXal1OtITvMMih5g 0uiMNsqNPaozujycEeXBd5n0+MMixEbDJRuVMyv2ZIVUr8FgK01hNJvbrpjc+A86F8Ep R/QjCckcGyQlpEBB9KCgI6TIkP6BU9DeX27QtKNrLI1Nl4+Ws15qPG6m3XFVS/GZ/ORY pGXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=a5Ddk2CZsypavy/NjZcPdSyGrnNPtgn1+uVKcCvRdr0=; b=XSsGd4F74lhcH/vDg6pWPVttcpYNRlibXTOMZDI+Sw+aLuEJbAxR3y18VFrDJz5OIO IFiS5x5TfiimLGD86cMzyiV/o2fVDJwkkBJo0H9j2kMRercxiG9dPJdGxlEl2TPRiXQs HZUC8ZOslFzn746aozBnw9Ez2ya0tnQ+SO/4d3LQAniebNZl74rwJUOsh4WXU/LiWRJG wkhBBnbCMPZlh8+pn1HqdkYqpKqH52dB9I/0hynJlvripZYOPYlr0+f5AgMjfN6rEblm 9C1EXNsLksYAWzfW0gtyXRdkY5vkEQx9PPkZ4pS5jEKbgxWsbTTEoLuyEillhrTb0yM7 f/uQ==
X-Gm-Message-State: AG10YORsOXWyxwKE7TMUpnFL9R3Z7lawcE4Lak/EfM7vNFq3nyF78aT9apmb71q96sN1XH7B3d4CcOLrTtFyOw==
MIME-Version: 1.0
X-Received: by 10.31.16.72 with SMTP id g69mr579550vki.152.1453437213761; Thu, 21 Jan 2016 20:33:33 -0800 (PST)
Received: by 10.31.106.130 with HTTP; Thu, 21 Jan 2016 20:33:33 -0800 (PST)
In-Reply-To: <CAMRcRGTZzfcAhmyfCKb6dgs72m97_ME5YYmGM8tQr+HrJJLoAw@mail.gmail.com>
References: <20160114143257.21051.19934.idtracker@ietfa.amsl.com> <CAMRcRGRJYtS8wxerPejv3QzmDavar_1ZYL5LytTN8YUzb7PcLQ@mail.gmail.com> <BBE9739C2C302046BD34B42713A1E2A22E920D28@ESESSMB105.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D188F6@ESESSMB209.ericsson.se> <CAMRcRGRZFnkGPyALu6=3L1xhSLpwHgiThgs9j-8Oh75=KteeEA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37D19CED@ESESSMB209.ericsson.se> <CAK35n0YDbyq9E2P_pjy3wcmr8VFr+yp689b6he-VPBh0D29KZQ@mail.gmail.com> <CAMRcRGTZzfcAhmyfCKb6dgs72m97_ME5YYmGM8tQr+HrJJLoAw@mail.gmail.com>
Date: Thu, 21 Jan 2016 20:33:33 -0800
Message-ID: <CAMRcRGTW2thwJ-LtKfZRG_TFw4rHJLk1H+u-tOKt9KGBVEwRrg@mail.gmail.com>
From: Suhas Nandakumar <suhasietf@gmail.com>
To: Taylor Brandstetter <deadbeef@google.com>
Content-Type: multipart/alternative; boundary="001a114323f8d467490529e4b8f0"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/4Nqrb_ReNLzokNt8BBBjPiQrnGM>
Cc: mmusic WG <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-12.txt
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: <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: Fri, 22 Jan 2016 04:33:38 -0000

Hello Christer/Bo/Peter

  Do we think the understanding of dealing with the candidates when muxing
is clear or does either of the drafts needs more explanation on what needs
to be done.

Thanks
Suhas

On Mon, Jan 18, 2016 at 8:45 PM, Suhas Nandakumar <suhasietf@gmail.com>
wrote:

> I agree with Taylor.
>
> The Mux draft assigns category "TRANSPORT" to the ICE candidates. So the
> candidate information from the "m=" line which corresponds to the BUNDLED
> m=line shall be considered for the entire group.
>
> As far as implementation is concerned, i think one should be fine just
> trickling the candidate information for the m=line selected for a given
> BUNDLE group and no need to copy it for the rest unless there is a explicit
> need (Initial offer, plan to change the bundle group address, drop a
> m=line)  to include different candidates.
>
>  I would recommend we update the BUNDLE draft (if there is any confusion)
> to match the MUX draft unless people think otherwise.
>
> Hope this helps.
>
> Tanks
> Suhas
>
>
>
>
> On Fri, Jan 15, 2016 at 8:20 AM, Taylor Brandstetter <deadbeef@google.com>
> wrote:
>
>> "candidate" is in the TRANSPORT category though, which doesn't prevent it
>> from being different in different media sections. It's the BUNDLE
>> negotiation draft that imposes the candidate duplication requirement, with
>> a combination of these two paragraphs:
>>
>>    When the answerer selects a BUNDLE address for itself, referred to as
>>    the answerer BUNDLE address, it MUST associate that address with each
>>    bundled "m=" line within the created BUNDLE group in the answer.
>>
>>    When an offerer or answerer associates a shared address (i.e. a
>>    previously selected BUNDLE address) with one or more bundled "m="
>>    lines, it MUST associate identical ICE candidates (referred to as
>>    shared ICE candidates) with each of those "m=" lines.
>>
>>
>> On Fri, Jan 15, 2016 at 4:29 AM, Christer Holmberg <
>> christer.holmberg@ericsson.com> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> There is also another issue:
>>>
>>>
>>>
>>> Some time ago, Peter Thatcher asked whether it is really needed to
>>> include the SDP candidate attributes in all bundled m- lines.
>>>
>>>
>>>
>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg15331.html
>>>
>>>
>>>
>>> Looking at SDP attributes in general, I guess the question is: if an
>>> attribute belongs to IDENTICAL, does it need to be included in all m- lines
>>> within a BUNDLE group?
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> Christer
>>>
>>>
>>>
>>> *From:* Suhas Nandakumar [mailto:suhasietf@gmail.com]
>>> *Sent:* 14. tammikuuta 2016 22:51
>>> *To:* Christer Holmberg
>>> *Cc:* Bo Burman; mmusic WG; Taylor Brandstetter
>>>
>>> *Subject:* Re: [MMUSIC] I-D Action:
>>> draft-ietf-mmusic-sdp-mux-attributes-12.txt
>>>
>>>
>>>
>>> Thanks Christer for bringing this to our notice. I just responded to
>>> Taylor's clarification question and I don't  think the response to his
>>> question changes any of the behavior for BUNDLE or MUX.
>>>
>>>
>>>
>>> Please let me know your thoughts on my response.
>>>
>>>
>>>
>>> Thanks
>>>
>>> Suhas
>>>
>>>
>>>
>>> On Thu, Jan 14, 2016 at 12:06 PM, Christer Holmberg <
>>> christer.holmberg@ericsson.com> wrote:
>>>
>>> Hold on :)
>>>
>>>
>>>
>>> Some time ago there was a question from Taylor Brandstetter. Was that
>>> solved? The topic mentioned BUNDLE, but I think the question was also
>>> related to the sdp-mux-attribute draft.
>>>
>>>
>>>
>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg15421.html
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> Christer
>>>
>>>
>>>
>>> *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Bo Burman
>>> *Sent:* 14 January 2016 18:09
>>> *To:* Suhas Nandakumar <suhasietf@gmail.com>
>>> *Cc:* mmusic WG <mmusic@ietf.org>
>>>
>>>
>>> *Subject:* Re: [MMUSIC] I-D Action:
>>> draft-ietf-mmusic-sdp-mux-attributes-12.txt
>>>
>>>
>>>
>>> Thank you Suhas,
>>>
>>>
>>>
>>> I believe this version addresses all comments provided, has no remaining
>>> nits, and I thus intend to use it for the publication request.
>>>
>>>
>>>
>>> Cheers,
>>>
>>> /Bo
>>>
>>> MMUSIC co-chair
>>>
>>>
>>>
>>> *From:* mmusic [mailto:mmusic-bounces@ietf.org <mmusic-bounces@ietf.org>]
>>> *On Behalf Of *Suhas Nandakumar
>>> *Sent:* den 14 januari 2016 15:34
>>> *To:* internet-drafts@ietf.org
>>> *Cc:* mmusic WG; i-d-announce@ietf.org
>>> *Subject:* Re: [MMUSIC] I-D Action:
>>> draft-ietf-mmusic-sdp-mux-attributes-12.txt
>>>
>>>
>>>
>>> Hello All
>>>
>>>
>>>
>>> This version fixes couple of ID nits and updates the references to the
>>> latest RFCs.
>>>
>>>
>>>
>>>
>>>
>>> Cheers
>>>
>>> suhas
>>>
>>>
>>>
>>> On Thu, Jan 14, 2016 at 6:32 AM, <internet-drafts@ietf.org> wrote:
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>  This draft is a work item of the Multiparty Multimedia Session Control
>>> Working Group of the IETF.
>>>
>>>         Title           : A Framework for SDP Attributes when
>>> Multiplexing
>>>         Author          : Suhas Nandakumar
>>>         Filename        : draft-ietf-mmusic-sdp-mux-attributes-12.txt
>>>         Pages           : 96
>>>         Date            : 2016-01-14
>>>
>>> Abstract:
>>>    The Session Description Protocol (SDP) provides mechanisms to
>>>    describe attributes of multimedia sessions and of individual media
>>>    streams (e.g., Real-time Transport Protocol (RTP) sessions) within a
>>>    multimedia session.  Typically media associated with individual media
>>>    descriptions ("m=" lines) represent RTP sessions and are thus carried
>>>    over individual underlying transport layer flows.  For scenarios
>>>    where SDP is used to negotiate the usage of single 5-tuple for
>>>    sending and receiving media associated with multiple media
>>>    descriptions, it is required to understand the semantic implications
>>>    of the SDP attributes associated with the RTP Media Streams
>>>    multiplexed over a single underlying transport layer flow.
>>>
>>>    The purpose of this specification is to provide a framework for
>>>    analyzing the multiplexing characteristics of SDP attributes.  This
>>>    specification also categorizes the existing SDP attributes based on
>>>    the framework described herein.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/
>>>
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-12
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-mux-attributes-12
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>>
>>>
>>>
>>>
>>
>>
>