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

[Roni Even <[e-mail]>]

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:[e-mail]]
> Sent: יום ה 02 פברואר 2017 04:45
> To: Roni Even
> Cc: [e-mail]; [e-mail]
> Subject: Re: [AVTCORE] Need feedback on RFC5285bis (RTP header
> extensions) comments
> 
> 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