Return-Path: 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 7A0621294BE for ; Mon, 27 Mar 2017 10:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 tFbDUbb9lDxV for ; Mon, 27 Mar 2017 10:55:29 -0700 (PDT) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (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 82168129482 for ; Mon, 27 Mar 2017 10:55:29 -0700 (PDT) Received: by mail-ot0-x22f.google.com with SMTP id a5so36043881oth.1 for ; Mon, 27 Mar 2017 10:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=xSENfN2hANUoabUZ4D+1zTPLSHHNnG8WPN5xHm4Q6g4=; b=jU0d5lpTqi6CTaSoSAzdWOWTB5WktcEfbHNPdroH6iCtzilrPT4Ueg2WTYsSTWw+o3 9tAcw6WFBBESjnzVcRtcF4U/T3cfBVTqH1aHgsIuiYHXHGDZgusjxIqHxfQfBwAfWzPw Cd659uiABMenUroOnMvyIy3duHcIP45+0Ewiz8ct8nxzWc3FpqjjDZVmDIzzMmtqnkOb rgT8/JnjaFRfXtS9UL/eTEevBQ7z0hk60yMZ0YbRIlEF1kJAZ1xajcoQpVvnnN0XU3FT CzHdTGaD97jrz1JE/M+JHlAOitiQ3h8cUgXYgb8OC1XqxPvKFD2SyLkY59bJ/BOohe2n tIbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=xSENfN2hANUoabUZ4D+1zTPLSHHNnG8WPN5xHm4Q6g4=; b=fsIU//PBR6g1FxrYkChlYwRlBJ5Ou2+zyVw8udBsyt36MZ6KygTDTgdlaNml8j/8jr O0w9M/QZus82WLBNHuS5c2hK4e6ThbFR6HOBFFGG0em99cqWXkT/Onmki8fGmcrsueXJ ad6RnXA6awLmE2Uk+Urhlmio+cwcKFhpdWs7+KNVpIAs5T0XOR101H6VrDFnaTt80alh Tr3qrizQAtX1UfF2gixFkp9oLyvnfAp9IWbTB7xaxcpLhV/XuoCahp49fO0v/USOk1av vnfw9gFqjeVXdF0+MeUUSJF5In5chsIIOPiSDVL7Qwuajza4uoaee9m9z426JZAOAdr+ AR4w== X-Gm-Message-State: AFeK/H0/0TGiCzmrPzIwLjcESNqE9+zcQSr3ywLZypnG2WA/t29U1ZQiOLA+8QrfuPTOOQ== X-Received: by 10.157.83.27 with SMTP id g27mr13282466oth.160.1490637328931; Mon, 27 Mar 2017 10:55:28 -0700 (PDT) Received: from ?IPv6:2602:301:77fd:e0a0:5477:d084:ffa2:a5de? ([2602:301:77fd:e0a0:5477:d084:ffa2:a5de]) by smtp.googlemail.com with ESMTPSA id s133sm512814oif.9.2017.03.27.10.55.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Mar 2017 10:55:28 -0700 (PDT) To: Taylor Brandstetter , =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= References: Cc: mmusic WG From: Byron Campen Message-ID: <279829dc-201f-25ab-0d1b-9958fb98682f@gmail.com> Date: Mon, 27 Mar 2017 12:55:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8927E9E8F87B8C979DC8E983" Archived-At: Subject: Re: [MMUSIC] "a=extmap" with BUNDLE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 17:55:31 -0000 This is a multi-part message in MIME format. --------------8927E9E8F87B8C979DC8E983 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Would it not be sufficient to specify that bundled m-sections not use the same identifier for _different_ extensions? There's no ambiguity if you use '3' for mid on every m-section, which is the kind of thing implementations do now anyway. Best regards, Byron Campen On 3/27/17 12:44 PM, Taylor Brandstetter wrote: > If extension IDs aren't unique across bundled m= sections, then on > receiving a packet, an implementation may need to determine which m= > section it's "associated" with before knowing how to interpret the > extension IDs. To do this, it may need to use the MID, which means > that at a minimum, the MID extension must be using a unique ID. > > But this increases implementation complexity without much benefit (the > benefit being that by sharing IDs, you could more easily avoid running > out of spare IDs). So I'd be in favor of just requiring them to be unique. > > On Sat, Mar 25, 2017 at 6:35 PM, Iņaki Baz Castillo > wrote: > > 2017-03-24 19:28 GMT+01:00 Taylor Brandstetter > >: > > saw that. Which means that individual documents are responsible > for defining > > how their extensions work with BUNDLE. > > > > But something still would need to define the general > restrictions for using > > "extmap" with BUNDLE, such as the ID restriction. Or is that > just something > > that's common sense and doesn't need to be specified? > > https://tools.ietf.org/html/rfc5285#section-6 > just mandates that the > IDs must be unique within a m= section, but at the end, all the WebRC > implementations use unique ID values across the entire SDP. > > There are some RTP extensions, such as > http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01 > , > that work at *transport* level (rather than at m= section level), but > nothing prevents such a spec to work even if its ID is not unique > within the m= sections. > > This is, IMHO we don't need a global behavior/requirement for the ID > values within bundled m= sections. > > > -- > Iņaki Baz Castillo > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------8927E9E8F87B8C979DC8E983 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
    Would it not be sufficient to specify that bundled m-sections not use the same identifier for _different_ extensions? There's no ambiguity if you use '3' for mid on every m-section, which is the kind of thing implementations do now anyway.

Best regards,
Byron Campen

On 3/27/17 12:44 PM, Taylor Brandstetter wrote:
If extension IDs aren't unique across bundled m= sections, then on receiving a packet, an implementation may need to determine which m= section it's "associated" with before knowing how to interpret the extension IDs. To do this, it may need to use the MID, which means that at a minimum, the MID extension must be using a unique ID.

But this increases implementation complexity without much benefit (the benefit being that by sharing IDs, you could more easily avoid running out of spare IDs). So I'd be in favor of just requiring them to be unique.

On Sat, Mar 25, 2017 at 6:35 PM, Iņaki Baz Castillo <ibc@aliax.net> wrote:
2017-03-24 19:28 GMT+01:00 Taylor Brandstetter <deadbeef@google.com>:
> saw that. Which means that individual documents are responsible for defining
> how their extensions work with BUNDLE.
>
> But something still would need to define the general restrictions for using
> "extmap" with BUNDLE, such as the ID restriction. Or is that just something
> that's common sense and doesn't need to be specified?

https://tools.ietf.org/html/rfc5285#section-6 just mandates that the
IDs must be unique within a m= section, but at the end, all the WebRC
implementations use unique ID values across the entire SDP.

There are some RTP extensions, such as
http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01,
that work at *transport* level (rather than at m= section level), but
nothing prevents such a spec to work even if its ID is not unique
within the m= sections.

This is, IMHO we don't need a global behavior/requirement for the ID
values within bundled m= sections.


--
Iņaki Baz Castillo
<ibc@aliax.net>



_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


--------------8927E9E8F87B8C979DC8E983--