Subject: [AVTCORE] RFC5285bis open issues

From: Roni Even <[email-masked]>
Date: Sun, 19 Feb 2017 15:06:46 +0000

Hi,
Based on the email discussion I see some issues that need conclusion

1.       For the one-byte RTP header extension if id=0 and len>0 what action to take since there is no current text

a.       This is also padding

b.      This is an error so stop interpreting following header extensions - similar to id=15

2.       Can we conclude from RFC5285 that if only IDs between 1-14 are offered it means that only one-byte RTP header extension are supported?

Thanks
Roni Even
As editor of RFC5285bis

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 20 Feb 2017 10:46:50 +0100

Hi,

Personal opinions, not responding as WG chair and doc shepherd.

Den 2017-02-19 kl. 16:06, skrev Roni Even:
> 1.       For the one-byte RTP header extension if id=0 and len>0 what
> action to take since there is no current text
>
> a.       This is also padding
>
> b.      This is an error so stop interpreting following header
> extensions – similar to id=15
>

 From my perspective, RFC 5285 is very clear that padding is a byte with 
value 0, i.e. all 8  bits are zero. Also, sending for example 0x04 is 
very undefined and a sender could expect b) option response from the 
receiver. Without agreed interpretation I rather send a clear message, 
don't use this. Thus, I would favour option b).

> 2.       Can we conclude from RFC5285 that if only IDs between 1-14 are
> offered it means that only one-byte RTP header extension are supported?
>

I think I have been involved in discussion about this previously. The 
conclusion I remember is that it is not possible. It is allowed to 
negotiate IDs below 16 and still use the two-byte header format for a 
particular RTP stream. So, it is not a conclusion we can draw.

However, the reality was that until we created the SDES header extension 
we didn't have any header extension that had the possibility to be more 
than 16 bytes.

At least if I remember correctly how the definition of the various 
registered header extensions.
http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-10

But, there could exist proprietary header extensions that are longer.

So, not guaranteed, but a fairly safe bet assuming no header extensions 
that are known to allow longer than 16 bytes. But, I think one has to 
make it clear that there are no guarantees, but one could write a 
guideline for a case that is likely to work.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Roni Even <[email-masked]>
Date: Sun, 26 Feb 2017 07:30:47 +0000

Hi Magnus,
Thanks,
I will add the text about the id=0 len>0 using option b

As for support for one-byte only I think that since section 4.1.2 says " the one-byte header form is preferred and MUST be supported by
   all receivers" it provides guideline to use one-byte saying that one-byte will work but two-bytes may not. Do you have another proposed text to address this point?

Roni

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: יום ב 20 פברואר 2017 11:47
> To: Roni Even; [email-masked]
> Subject: Re: [AVTCORE] RFC5285bis open issues
> 
> Hi,
> 
>  From my perspective, RFC 5285 is very clear that padding is a byte with value
> 0, i.e. all 8  bits are zero. Also, sending for example 0x04 is very undefined
> and a sender could expect b) option response from the receiver. Without
> agreed interpretation I rather send a clear message, don't use this. Thus, I
> would favour option b).
> 
> 
> conclusion I remember is that it is not possible. It is allowed to negotiate IDs
> below 16 and still use the two-byte header format for a particular RTP
> stream. So, it is not a conclusion we can draw.
> 
> we didn't have any header extension that had the possibility to be more than
> 16 bytes.
> 
> At least if I remember correctly how the definition of the various registered
> header extensions.
> So, not guaranteed, but a fairly safe bet assuming no header extensions that
> are known to allow longer than 16 bytes. But, I think one has to make it clear
> that there are no guarantees, but one could write a guideline for a case that
> is likely to work.
> 
> Cheers
> 
> Magnus Westerlund
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Feb 2017 11:24:38 +0100

> I will add the text about the id=0 len>0 using option b

Regarding this text:

    Each distinct extension MUST have a unique ID.
    The value 0 is reserved for padding and MUST NOT be used as a local
    identifier.

    an extension element with a value equal 0 MUST NOT have len greater
    than 0.  If such an extension element is encountered, its length
    field MUST be ignored, processing of the entire extension MUST
    terminate at that point, and only the extension elements present
    prior to the element with ID 0 and len greater than 0 SHOULD be
    considered.

I think it could be improved to make it clearer, thus I suggest the 
following changed:

    Each distinct extension MUST have a unique ID.
    The ID value 0 is reserved for padding and MUST NOT be used as a
        ^^
    local identifier.

    An extension element with an ID value equal 0 MUST NOT have len
    ^                          ^^^^
    greater
    than 0.  If such an extension element is encountered, its length
    field MUST be ignored, processing of the entire extension MUST
    terminate at that point, and only the extension elements present
    prior to the element with ID 0 and len greater than 0 SHOULD be
    considered.

>    all receivers" it provides guideline to use one-byte saying that one-byte will work but two-bytes may not. Do you have another proposed text to address this point?

No, I don't have any suggestion for improving that text.

Cheers

Magnus Westerlund

---

From: Roni Even <[email-masked]>
Date: Mon, 27 Feb 2017 11:23:08 +0000

Hi Magnus,
Submitted 08 version with your changes.
I think this version addresses the WGLC comments.
Roni

> Sent: יום ב 27 פברואר 2017 12:25
> I think it could be improved to make it clearer, thus I suggest the following
> changed:
> 
> > As for support for one-byte only I think that since section 4.1.2 says " the
> one-byte header form is preferred and MUST be supported by
> >    all receivers" it provides guideline to use one-byte saying that one-byte
> will work but two-bytes may not. Do you have another proposed text to
> address this point?
>