Subject: [rtcweb] Replacing a=extmap mapping in re-offer, is it legal?

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 7 Aug 2017 16:06:00 +0200

Hi,

Let's assume that Alice sends a offer to Bob with a single m=video
section that contains:

  a=extmap:11 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time

Bob replies with the same extmap.

Later Bob generates a re-offer and it looks like this:

  a=extmap:1 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
  a=extmap:2 urn:ietf:params:rtp-hdrext:toffset

Is this legal? Couldn't find nothing about renegotiations in
https://tools.ietf.org/html/rfc5285, however it looks to me that the
world would be better if the already negotiated extension mapping is
kept.

Said that, Chrome does keep the previously negotiated ext mapping, but
Firefox does not, behaving exactly as shown above.

Bug report in Firefox tracker:
https://bugzilla.mozilla.org/show_bug.cgi?id=1384064

JSFiddle reproducing it (open the devtool console):
https://jsfiddle.net/ibcaliax/uan2fove/

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 Aug 2017 14:10:24 +0000

Hi,

My assumption is that it by default is always allowed to re-negotiate SDP attribute values. And, if it's not, it should be explicitly indicated.

You said that Chrome keeps the previously negotiated value. Does Chrome still accept the new offer?

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Iñaki Baz Castillo
Sent: 07 August 2017 16:06
To: [email-masked]
Subject: [rtcweb] Replacing a=extmap mapping in re-offer, is it legal?

Hi,

Let's assume that Alice sends a offer to Bob with a single m=video section that contains:

Is this legal? Couldn't find nothing about renegotiations in https://tools.ietf.org/html/rfc5285, however it looks to me that the world would be better if the already negotiated extension mapping is kept.

Said that, Chrome does keep the previously negotiated ext mapping, but Firefox does not, behaving exactly as shown above.

--
Iñaki Baz Castillo
<[email-masked]>

_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 7 Aug 2017 16:18:16 +0200

> My assumption is that it by default is always allowed to re-negotiate SDP attribute values. And, if it's not, it should be explicitly indicated.

SDP O/A is really error prune. This must end. It cannot happen that,
for every renegotiation (which may be it just wants to add/remove a
track) everything regarding ICE, DTLS, codecs. extmap, etc etc must be
re-inspected.

> You said that Chrome keeps the previously negotiated value. Does Chrome still accept the new offer?

AFAIR it does not complain, but it's hard to know whether Chrome keeps
the previously negotiated ext mapping or respects the new one, since
another "SDP O/A related bug" happens:

https://bugzilla.mozilla.org/show_bug.cgi?id=1247725

This is really crazy. I hope we can drop SDP from WebRTC soon. This is not sane.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Taylor Brandstetter <[email-masked]>
Date: Mon, 7 Aug 2017 10:46:10 -0700

I don't know if this is stated explicitly anywhere, but my assumption was
that it works like payload types. You can introduce new IDs all you want,
but you can't have one ID refer to multiple things during the same session.
Otherwise, if you receive a packet with that extension ID, you wouldn't be
able to tell which extension it is.

Meaning, if Bob's initial answer was:

It would be illegal to have a re-offer of:

a=extmap:1 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:11 urn:ietf:params:rtp-hdrext:toffset

Because if Bob then receives a packet with extension ID 11, Bob doesn't
know if it's a packet sent before Alice received the answer (in which case
it's "abs-send-time"), or after (in which case it's "toffset").

On Mon, Aug 7, 2017 at 7:18 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> > My assumption is that it by default is always allowed to re-negotiate
> SDP attribute values. And, if it's not, it should be explicitly indicated.
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 7 Aug 2017 19:55:46 +0200

On Mon, Aug 7, 2017 at 7:46 PM, Taylor Brandstetter <[email-masked]> wrote:
> Because if Bob then receives a packet with extension ID 11, Bob doesn't know
> if it's a packet sent before Alice received the answer (in which case it's
> "abs-send-time"), or after (in which case it's "toffset").

Thanks, your rationale clearly makes sense. However:

1) I don't think Firefox cares about overriding a previous extmap ID
during a reoffer.

2) Should we really accept so complex and error prune things just
because SDP allows everything?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 Aug 2017 18:01:42 +0000

Hi,

Taylor's explanation makes sense. But, in this case:

1) Re-using the same value with a new mapping should be an explicit MUST NOT

2) The re-offer should be rejected

Regards,

Christer

-----Original Message-----
From: Iñaki Baz Castillo [mailto:[email-masked]] 
Sent: 07 August 2017 19:56
To: Taylor Brandstetter <[email-masked]>
Cc: Christer Holmberg <[email-masked]>; [email-masked]
Subject: Re: [rtcweb] Replacing a=extmap mapping in re-offer, is it legal?

On Mon, Aug 7, 2017 at 7:46 PM, Taylor Brandstetter <[email-masked]> wrote:
> I don't know if this is stated explicitly anywhere, but my assumption 
> was that it works like payload types. You can introduce new IDs all 
> you want, but you can't have one ID refer to multiple things during the same session.
> Otherwise, if you receive a packet with that extension ID, you 
> wouldn't be able to tell which extension it is.
>
> Because if Bob then receives a packet with extension ID 11, Bob 
> doesn't know if it's a packet sent before Alice received the answer 
> (in which case it's "abs-send-time"), or after (in which case it's "toffset").

1) I don't think Firefox cares about overriding a previous extmap ID during a reoffer.

2) Should we really accept so complex and error prune things just because SDP allows everything?

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 7 Aug 2017 20:03:23 +0200

> 2) The re-offer should be rejected

Hi Christer, I'm lost. If Taylor's explanation is ok, why 1) and 2)?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 Aug 2017 18:04:31 +0000

Hi,

> SDP O/A is really error prune. This must end. It cannot happen that, for every renegotiation (which may be it just wants to add/remove a
> track) everything regarding ICE, DTLS, codecs. extmap, etc etc must be re-inspected.

All m- lines obviously need to be included in each re-offer (unless we progress draft-pof-pan), but one can always define that if an attribute is not included in a re-offer the previous value apply.

In this case, however, I don't think everything-must-be-re-inspected is the issue. The issue is whether it's allowed to change the attribute value mapping to begin with.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 Aug 2017 18:06:56 +0000

Hi,

> Hi Christer, I'm lost. If Taylor's explanation is ok, why 1) and 2)?

Maybe I was unclear :)

Taylor described why re-using a value for a new mapping doesn't work. I think that should be explicitly described, and the text should say MUST NOT re-use value for new mapping (hence 1).

Second, IF an offerer still tries to re-use a value for a new mapping, the text should say that the receiver MUST discard the offer (hence 2).

Regards,

Christer

---

From: Taylor Brandstetter <[email-masked]>
Date: Mon, 7 Aug 2017 11:21:39 -0700

Christer and I are in agreement. He's just saying "there should be a MUST
NOT in the spec."

And there is:

Identifiers values in the valid range MUST NOT be altered (remapped).

On Mon, Aug 7, 2017 at 11:06 AM, Christer Holmberg <
[email-masked]> wrote:

> Taylor described why re-using a value for a new mapping doesn't work. I
> think that should be explicitly described, and the text should say MUST NOT
> re-use value for new mapping (hence 1).
>
> Second, IF an offerer still tries to re-use a value for a new mapping, the
> text should say that the receiver MUST discard the offer (hence 2).
>
> Regards,
>
> Christer
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 7 Aug 2017 21:12:12 +0200

Good catch.

On Mon, Aug 7, 2017 at 8:21 PM, Taylor Brandstetter <[email-masked]> wrote:
> On Mon, Aug 7, 2017 at 11:06 AM, Christer Holmberg

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roni Even <[email-masked]>
Date: Wed, 9 Aug 2017 05:27:41 +0000

Hi,
Inline
Roni Even

> From: rtcweb [mailto:[email-masked]] On Behalf Of Christer
> Holmberg
> Sent: יום ב 07 אוגוסט 2017 21:02
> To: Iñaki Baz Castillo; Taylor Brandstetter
> Cc: [email-masked]
[Roni Even] This is specified in RFC5285 section 6

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 9 Aug 2017 12:26:41 +0000

Hi,

>Identifiers values in the valid range MUST NOT  be altered (remapped).

Correct. Taylor indicated this earlier.

What if a previously negotiated mapping is not included at all in a subsequent offer? Is it considered an error? If not, does the previous mapping apply? Or, is the previous mapping removed?

Regards,

Christer

> > I don't know if this is stated explicitly anywhere, but my 
> > assumption was that it works like payload types. You can introduce 
> > new IDs all you want, but you can't have one ID refer to multiple 
> > things during the
> same session.

---

From: Roni Even <[email-masked]>
Date: Wed, 9 Aug 2017 13:43:29 +0000

Hi Christer,
Inline, cc avtcore since it is avtcore document .
Look at https://tools.ietf.org/html/draft-ietf-avtcore-rfc5285-bis-14#section-7 
Roni

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: יום ד 09 אוגוסט 2017 15:27
> To: Roni Even; Iñaki Baz Castillo; Taylor Brandstetter
> Cc: [email-masked]
> Subject: RE: [rtcweb] Replacing a=extmap mapping in re-offer, is it legal?
> 
> Hi,
> 
> What if a previously negotiated mapping is not included at all in a subsequent
> offer?

[Roni Even] It is removed not supported "A session update MAY add or  remove extension(s)."

 Is it considered an error?

[Roni Even] no

 If not, does the previous mapping apply? 
[Roni Even] if you want to use it you can consider making it inactive

Or,
> is the previous mapping removed?
[Roni Even] removed but you cannot use the same ID for another extension

> > > a=extmap:11 http://www.webrtc.org/experiments/rtp-hdrext/abs-
> send-
> > time
> > >