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

[[e-mail] (Dale R. Worley)]

Roni Even <[e-mail]> writes:
> Paul made a very thorough SDP review and had some comments on which I
> am looking for feedback.

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.

> 2.       In this case if the offer is refused by removing the extmap
> 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.

> 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.

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.

> 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

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