[straw] Alissa Cooper's Discuss on draft-ietf-straw-b2bua-rtcp-15: (with DISCUSS and COMMENT)

["Alissa Cooper" <[e-mail]>]

Alissa Cooper has entered the following ballot position for
draft-ietf-straw-b2bua-rtcp-15: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

= Section 3.1 =

I think there is a lack of clarity in the recommendations here, because
"such attributes" aren't listed out anywhere and then later it's not
clear what the "mentioned attributes" are referring to. I've proposed
some edits below to try to clarify what I think the recommendations are
saying -- does this capture the intent? 

OLD
However, certain SDP attributes may
   lead to call failures when forwarded by a media relay.  Such
   attributes SHOULD NOT be forwarded.  One notable example is the
   'rtcp' [RFC3605] attribute, that UAC may make use of to explicitly
   state the port they're willing to use for RTCP.  Considering the
   B2BUA would relay RTCP messages, the port as seen by the other UAC
   involved in the communication would differ from the one negotiated
   originally, and it MUST be rewritten accordingly.  Apart from the
   mentioned attributes, B2BUAs SHOULD forward all other SDP attributes
   they don't have a reason not to forward, in order to avoid breaking
   additional functionality endpoints may be relying on.

NEW
However, certain SDP attributes may
   lead to call failures when forwarded by a media relay. One notable
example is the
   'rtcp' [RFC3605] attribute, that UAC may make use of to explicitly
   state the port it is willing to use for RTCP. Assuming that the
   B2BUA would relay RTCP messages, the port as seen by the other UAC
   involved in the communication would differ from the one negotiated
   originally. The 'rtcp' attribute MUST be rewritten accordingly, rather
than being forwarded.  Any other attributes known to the B2BUA to cause
call failures when forwarded SHOULD NOT be forwarded. B2BUAs SHOULD
forward all other SDP attributes in order to avoid breaking additional
functionality endpoints may be relying on.

= Section 3.2 =

(1)
"It is worthwile to point out that such a B2BUA may not necessarily
   forward all the packets it receives, though.  Selective Forwarding
   Units (SFU) [RFC7667], for instance, may aggregate or drop incoming
   RTCP messages, while at the same time originating new ones on their
   own.  For the messages that are forwarded and/or aggregated, though,
   it's important to make sure the information is coherent."

I don't see much beyond this text that discusses the implications of
dropping and aggregating RTCP messages. Is this written down in another
document? If not, I'm wondering about what happens with RTCP information
aside from identifiers, SSRCs, and sequence numbers in these cases. E.g.,
if a B2BUA drops one RTCP message containing an RFC 7002 block but
forwards the next one containing such a block, won't the interval and the
discard count reported to the receiver be wrong? I assume there are a lot
of cases involving XR blocks where this could be a problem, but this
document doesn't address those cases.

(2)
"SR:  [RFC3550]
      If the B2BUA has changed the SSRC of the sender RTP stream a
      Sender Report refers to, it MUST update the SSRC in the SR packet
      header as well.  If the B2BUA has changed the SSRCs of other RTP
      streams too, and any of these streams are addressed in any of the
      SR report blocks, it MUST update the related values in the SR
      report blocks as well.  If the B2BUA has also changed the base RTP
      sequence number when forwarding RTP packets, then this change
      needs to be properly addressed in the 'extended highest sequence
      number received' field in the Report Blocks."

Why is the recommendation about the extended highest sequence number
received not also a MUST?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

= Section 3.2 =

s/properly address/reflected/