Subject: [AVTCORE] Need feedback on RFC5285bis (RTP header extensions) comments

From: Roni Even <[email-masked]>
Date: Wed, 1 Feb 2017 10:42:42 +0000

Hi,
Paul made a very thorough SDP review and had some comments on which I am looking for feedback.

1.       In section 7 "If an extension is marked as "sendonly" and the answerer desires to  receive it, the extension MUST be marked as "recvonly" in the SDP answer.  An answerer that has no desire to receive the extension or does not understand the extension SHOULD remove it from the SDP  answer." . Is there a reason for the "SHOULD" here or should we change it to "MUST" or maybe if not removed to  respond with "inactive"  or "sendonly" if want to send and and not receive?

2.       In this case if the offer is refused by removing the extmap line, can the ID be re-used?

3.        In section 7 "Local identifiers in the valid range inclusive in an offer or answer MUST NOT be used more than once per media section (including the session-level section).  A session update MAY change the direction qualifiers of extensions under use.  A session update MAY add or remove extension(s).  Identifiers values in the valid range MUST NOT be altered (remapped)." Paul asked what is the scope over which identifiers must not be altered. His thought was only for the current RTP session so when a call is transferred (one party is still in the call) they may be altered. Any thoughts?

4.       Is it valid to use IDs in the (unusable) range in answers? (I guess that would give the offerer info that it could use in a future offer.). I am not sure what was meant here. Is it an answer to an offer with an ID in the valid range? Or is it about keeping an alternative from the offer with the unusable space and not remove it? I assume that the answer cannot add extensions to the ones in the offer, will need a new offer for that.

5.       May values from the (unused) range that are used in offers (or answers) be reused differently in subsequent offers?

6.       Would the following be valid? (Only the directionality differs.)

     OFFER:

     a=extmap:4096/sendonly http://example.com/082005/ext.htm#opt1

     a=extmap:4096/recvonly http://example.com/082005/ext.htm#opt1

7.       Is it allowed to use the "alternatives" mechanism with only a single alternative? This would be a way to avoid "wasting" an ID value until you know if your peer supports the option. I see this usage in an example, but it is not mentioned in text. If this is an intended usage then it would be good to provide some further explanation.

Thanks

Roni Even

As the document editor.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 1 Feb 2017 13:48:04 -0500

On 2/1/17 5:42 AM, Roni Even wrote:

> 4.       Is it valid to use IDs in the (unusable) range in answers? (I
> guess that would give the offerer info that it could use in a future
> offer.). I am not sure what was meant here. Is it an answer to an offer
> with an ID in the valid range? Or is it about keeping an alternative
> from the offer with the unusable space and not remove it? I assume that
> the answer cannot add extensions to the ones in the offer, will need a
> new offer for that.

Clarifying what I meant:

My first question is: is it valid an extmap attribute with an ID in the 
(unusable) range appear in an SDP answer?

If the answer to that is Yes, then a followon question is: what does 
that mean?

It occurred to me that it might be used by the answerer to indicate to 
the offerer some extensions that it is willing to use that were not 
mentioned in the offer.

I ask this mostly for completeness - the spec is silent on the matter.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 01 Feb 2017 21:45:25 -0500

> Paul made a very thorough SDP review and had some comments on which I

I didn't realize that this draft was so interesting.  Given that it's
still under review, even though it's a month after the official end of
the last call, I'll post my full comments later.  In the mean time:

> 1.       In section 7 "If an extension is marked as "sendonly" and the
> answerer desires to  receive it, the extension MUST be marked as
> "recvonly" in the SDP answer.  An answerer that has no desire to
> receive the extension or does not understand the extension SHOULD
> remove it from the SDP  answer." . Is there a reason for the "SHOULD"
> here or should we change it to "MUST" or maybe if not removed to
> respond with "inactive"  or "sendonly" if want to send and and not
> receive?

I think the idea is that if the offer contains "sendonly" and the
answerer wants to receive it, then the answer must contain "recvonly".
But if the answerer doesn't want to receive it, then the answerer must
set it to "inactive" or remove the attribute, and the latter is
preferred.  At least, that makes sense, and it makes the MUSTs and
SHOULDs correct, though that's probably not the clearest way to express
the meaning.

> line, can the ID be re-used?

I think the point of this text in section 7 is that if an extension
identifier could get used in RTP packets (i.e., is in the answer), then
a session update can't immediately define that identifier to a new URI:

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

That protects packets in flight from misinterpretation.

But if the extension identifier isn't accepted in the offer, then there's
no problem with packets in flight, and the next session update can
allocate the identifier to a different extension.

However, this text in section 7 seems to say that if an identifier is in
the offer, even if it isn't in the answer, both endpoints can use it:

   Either party MAY include extensions in the stream other than those
   negotiated, or those negotiated as "inactive", for example, for the
   benefit of intermediate nodes.  Only extensions that appeared with an
   identifier in the valid range in SDP originated by the sender can be
   sent.

In that case, packets in flight could be using an identifier that was
not accepted in the answer.

My opinion is that the latter text is not a good idea.

> 3.        In section 7 "Local identifiers in the valid range inclusive
> in an offer or answer MUST NOT be used more than once per media
> section (including the session-level section).  A session update MAY
> change the direction qualifiers of extensions under use.  A session
> update MAY add or remove extension(s).  Identifiers values in the
> valid range MUST NOT be altered (remapped)." Paul asked what is the
> scope over which identifiers must not be altered. His thought was only
> for the current RTP session so when a call is transferred (one party
> is still in the call) they may be altered. Any thoughts?

Good point -- this is the same problem as reusing RTP payload types.  In
theory you don't want to reuse them at all, or at least, not use them
for different encodings immediately before and after one single session
update, because there may be packets in flight using that payload type.
But various call transfer and 3PCC scenarios make that very difficult to
ensure in practice.

> offer.). I am not sure what was meant here. Is it an answer to an
> offer with an ID in the valid range? Or is it about keeping an
> alternative from the offer with the unusable space and not remove it?
> I assume that the answer cannot add extensions to the ones in the
> offer, will need a new offer for that.

I think it's a mechanism to allow the answerer to say "I support that
extension" even if it can't allocate a valid identifier for it, or if it
doesn't want to use the extension now.  (But see the second quoted
passage under item 2 and its discussion.)

Though it's not clear to me how useful that facility is.  In general, a
UA should always offer everything that it is willing to support because
any information it has cached about the capabilities/desires of the
other endpoint could be invalid now.

> 5.       May values from the (unused) range that are used in offers
> (or answers) be reused differently in subsequent offers?

I believe the intention is that they may be reused.  The text does not
forbid that:

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

And there is no packets-in-flight problem.

>      a=extmap:4096/recvonly http://example.com/082005/ext.htm#opt1

That's subtle:  the identifier is mapped to the same extension in both
directions, but each direction is mapped by a different extmap
attribute.  Yeah, that's forbidden in section 5:

   In addition, as noted above,
   the IDs used MUST be unique for each stream type for a given media,
   or for the session for session-level declarations.

> 7.       Is it allowed to use the "alternatives" mechanism with only a
> single alternative? This would be a way to avoid "wasting" an ID value
> until you know if your peer supports the option. I see this usage in
> an example, but it is not mentioned in text. If this is an intended
> usage then it would be good to provide some further explanation.

Well, it isn't an "alternative" construction because there's only one
attribute with that identifier.  But it's not forbidden to write just
one attribute with an extended identifier value.  However, telling the
other UA that you support an extension isn't very useful, because the
next time the other UA updates the session, you may not be the UA on
this end of the call.

Dale

---

From: Roni Even <[email-masked]>
Date: Thu, 2 Feb 2017 06:18:36 +0000

Hi Dale,
I will look at all your comments but just to clarify rfc5285bis history.

This bis draft was created to add the support for mixing one byte and two bytes in an RTP session. It is good to clarify the text but we cannot change any RC5285 or RFC3550 policies in order to keep interoperability.
RFC5285 is an update to RFC3550 which allowed for RTP header extensions without any negotiation so for backward interoperability it is noted that RTP header extensions can appear in the RTP stream without being negotiated first, note that RTP header extensions can be ignored and the RTP will still be OK. 
This was not a late review by Paul but it was part of the SDP directorate review that is needed for all documents with SDP. 
Roni 

> -----Original Message-----
> From: Dale R. Worley [mailto:[email-masked]]
> Sent: יום ה 02 פברואר 2017 04:45
> To: Roni Even
> Cc: [email-masked]; [email-masked]
> Subject: Re: [AVTCORE] Need feedback on RFC5285bis (RTP header
> extensions) comments
> 
> I didn't realize that this draft was so interesting.  Given that it's still under
> review, even though it's a month after the official end of the last call, I'll post
> my full comments later.  In the mean time:
> 
> I think the idea is that if the offer contains "sendonly" and the answerer
> wants to receive it, then the answer must contain "recvonly".
> But if the answerer doesn't want to receive it, then the answerer must set it
> to "inactive" or remove the attribute, and the latter is preferred.  At least,
> that makes sense, and it makes the MUSTs and SHOULDs correct, though
> that's probably not the clearest way to express the meaning.
> 
> I think the point of this text in section 7 is that if an extension identifier could
> get used in RTP packets (i.e., is in the answer), then a session update can't
> immediately define that identifier to a new URI:
> 
> But if the extension identifier isn't accepted in the offer, then there's no
> problem with packets in flight, and the next session update can allocate the
> identifier to a different extension.
> 
> However, this text in section 7 seems to say that if an identifier is in the offer,
> even if it isn't in the answer, both endpoints can use it:
> 
> In that case, packets in flight could be using an identifier that was not
> accepted in the answer.
> 
> theory you don't want to reuse them at all, or at least, not use them for
> different encodings immediately before and after one single session update,
> because there may be packets in flight using that payload type.
> But various call transfer and 3PCC scenarios make that very difficult to ensure
> in practice.
> 
> extension" even if it can't allocate a valid identifier for it, or if it doesn't want
> to use the extension now.  (But see the second quoted passage under item 2
> and its discussion.)
> 
> Though it's not clear to me how useful that facility is.  In general, a UA should
> always offer everything that it is willing to support because any information it
> has cached about the capabilities/desires of the other endpoint could be
> invalid now.
> 
> I believe the intention is that they may be reused.  The text does not forbid
> that:
> 
> directions, but each direction is mapped by a different extmap attribute.
> Yeah, that's forbidden in section 5:
> 
> Well, it isn't an "alternative" construction because there's only one attribute
> with that identifier.  But it's not forbidden to write just one attribute with an
> extended identifier value.  However, telling the other UA that you support
> an extension isn't very useful, because the next time the other UA updates
> the session, you may not be the UA on this end of the call.
> 
> Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 02 Feb 2017 21:49:38 -0500

Roni Even <[email-masked]> writes:
> This bis draft was created to add the support for mixing one byte and
> two bytes in an RTP session. It is good to clarify the text but we
> cannot change any RC5285 or RFC3550 policies in order to keep
> interoperability.

Hmmm, yes, I hadn't figured that this was just a small modification of
5285.  There seem to be some places where the behavior it
specifies/allows is questionable.  Fortunately, I suppose, most of my
comments were about clarifying exactly what it means or making it easier
to see the overal structure.

I do think you could safely add that in the one-byte format, bytes 0x01
through 0x0F should be handled like bytes 0xF0 through 0xFF, as that is
now unspecified.

Dale

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 16 Feb 2017 14:48:20 +0100

> through 0x0F should be handled like bytes 0xF0 through 0xFF, as that is

Yes, I think that is a reasonable interpretation. A padding byte is 
0x00, and ID=0 and L=1-15 is not supported. Being explicit about this is 
fine and treat this as broken extension appear to me also as fine. I 
have assumed you are refering to the second sentence of this paragraph 
(Section 4.2):

    The local identifier value 15 is reserved for future extension and
    MUST NOT be used as an identifier.  If the ID value 15 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 15 SHOULD be
    considered.

You want something similar for ID value 0 with L>0?

There are a remote chance that such a behavior could result in 
discarding some extensions, and if one want to be more tolerant, then 
the alternative is to interpret anything with ID=0 as a padding byte.

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: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 16 Feb 2017 15:18:14 +0100

2017-02-01 11:42 GMT+01:00 Roni Even <[email-masked]>:
>   In section 7 “If an extension is marked as "sendonly" and the answerer
> desires to  receive it, the extension MUST be marked as "recvonly" in the
> SDP answer.

Is it so bad if the answer contains the same RTP extension with no direction?

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 16 Feb 2017 16:52:09 +0100

2017-02-16 16:19 GMT+01:00 Dale R. Worley <[email-masked]>:
> It seems to me that the handling of extension directions should be done
> in the same way as the SDP directionality attributes, where the
> directionality in the answer must be a subset of the directionality in
> the offer (accounting for the fact that the offer and the answer name
> directions with opposite polarity).  See e.g., RFC 3264 section 6.1.

Makes sense. It's just that it's a bit artificial. If a party sends
"sendonly" both of them already know that the other party can just
receive.

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