Re: [MMUSIC] "a=extmap" with BUNDLE

Taylor Brandstetter <deadbeef@google.com> Mon, 27 March 2017 22:24 UTC

Return-Path: <deadbeef@google.com>
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 D9929126E3A for <mmusic@ietfa.amsl.com>; Mon, 27 Mar 2017 15:24:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, 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=google.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 BV4UXgXGLoAe for <mmusic@ietfa.amsl.com>; Mon, 27 Mar 2017 15:24:24 -0700 (PDT)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 EAB90126BFD for <mmusic@ietf.org>; Mon, 27 Mar 2017 15:24:23 -0700 (PDT)
Received: by mail-qk0-x229.google.com with SMTP id f11so51622563qkb.0 for <mmusic@ietf.org>; Mon, 27 Mar 2017 15:24:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JhTJuTSmp1w5383fmDXKd+bwKollYzUISQFO71pX53A=; b=D1iqV3nGzKBHHMrk+9FxL3ul9b7UmLaeYC2zWwsNZGfk4KR9nacH2IGqHcHBASsmjV l88hvgomcSnK9cQaSLP42NLNiNUIpaVlxn9BMNxsaxm5UkzQxQ1TjsRqO88H4MZZXhTS ADMq+Jj05LF33m/+B06cI6VjXQq5IUfC+GGrywrljh8JXDMbiW9OvqFnQnFuYr79Wjtn +778mXIY5Jz5YAIBiDkLGw8Pt3T9CEvXe4tHBdmcHj/4810kw24u3aDidGCBdLEDTwa4 +6GTX0QIGMoxU8R8n3emi5ZhNWh5Rg6nvK51SjbL2YL+bcYB58vJJFDlM4Mn5mktGoRr 64uA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JhTJuTSmp1w5383fmDXKd+bwKollYzUISQFO71pX53A=; b=C/0fD7uoqjaMHm8R7yBIBHBlro3PAtirpR1/LJF4s3j4763NE5i6ur3i63BwkYDQrT lCzqWaVyC+fyDt5YUqSRMSPC2rElT+JyEBhNer2qZagRJnBGPOofyk5tWyzjterL5Qpl ULMziucwMhCjZRqcn1bQE6WF2X6KF5CYddig80I3kOY+3+sjmAn/oqs7tGAsAgrC7nyu c+3yqSOdw6bFcCIIImhSXRpMRsz4xaIOzersIEv//B7K7BaL6BL7FuJnLGn7ZNHLRNEK yV6G9GKtg5Wk1bjNUU1J4XXrrdDAKoyHV+E7kW3GzwWGbGGsAEmtFk3RWmf11jvsRRd8 GozQ==
X-Gm-Message-State: AFeK/H1WLTjXy6UXdkqENH2JsaeJUPjrj3Hl447wjHU97ZHRue0wNbt3B6SFHzFaK9Kg8yrBvUEtooz6rlibVI7R
X-Received: by 10.55.155.141 with SMTP id d135mr16076816qke.75.1490653462865; Mon, 27 Mar 2017 15:24:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.154.209 with HTTP; Mon, 27 Mar 2017 15:24:22 -0700 (PDT)
In-Reply-To: <CALiegfm33QGSuWDvJED5ERGEvHaJ6890X6hyqnjHr-ZkRCFSUg@mail.gmail.com>
References: <CAK35n0YEA8Cu_v33QsTHXRx70Jw6r-gYT_4rSjYvb6KR+YD81Q@mail.gmail.com> <CAMRcRGTJoOE0HLGwkdW261SiM+J3BCoAiDeq919d+YkyfhU6eg@mail.gmail.com> <CAK35n0ZMX6XVicnuvxHH16ADW5on0n18yK8_VDTLX7B1Gb0XDA@mail.gmail.com> <CALiegfmDH4a8nM08ify77pcz+az38KbJ3=x1n-dso7SYoODD1A@mail.gmail.com> <CAK35n0beszOvayncKgyC=JLZ+7ST_MW4awZ-VSMYt4qvNefX7A@mail.gmail.com> <279829dc-201f-25ab-0d1b-9958fb98682f@gmail.com> <CALiegfm33QGSuWDvJED5ERGEvHaJ6890X6hyqnjHr-ZkRCFSUg@mail.gmail.com>
From: Taylor Brandstetter <deadbeef@google.com>
Date: Mon, 27 Mar 2017 15:24:22 -0700
Message-ID: <CAK35n0YV0FK0f9obKVa6F8K4v5acA1M3y4hFk5cQ_b1cP89uaQ@mail.gmail.com>
To: Iñaki Baz Castillo <ibc@aliax.net>
Cc: Byron Campen <docfaraday@gmail.com>, mmusic WG <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c07684a23d5d8054bbdcec5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/VZ3h-hMwtJSy39KEMeUH5yhBkRM>
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 <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: Mon, 27 Mar 2017 22:24:26 -0000

>
> Would it not be sufficient to specify that bundled m-sections not use the
> same identifier for _different_ extensions?


Yes, that's what I meant to describe.

It's just about getting the appropriate RtpReceiver
> associated to the current RTP packet (this can be done by MID, RID,
> SSRC or even PT, as the ORTC and JSEP "RTP Matching Rules" define).


Right. So, if you *can't* get the appropriate RtpReceiver with RID, SSRC or
PT, then you must do it with MID. And if the MID extension shares an ID
with another extension, it becomes impossible to know the MID. For example:

m=audio ...
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:foo
m=video ...
a=extmap:1 urn:bar
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid

I know it would be crazy to generate SDP like that, but there's nothing
I've found that disallows it.

On Mon, Mar 27, 2017 at 2:00 PM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

> 2017-03-27 19:55 GMT+02:00 Byron Campen <docfaraday@gmail.com>:
> >   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.
>
> Still one may use '3' for MID within a m=audio line and '4' for MID
> within a m=video line. And that's legal.
> Anyhow, current browsers use unique IDs across the whole SDP.
>
>
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>
>