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

[Lorenzo Miniero <[e-mail]>]

On Tue, 29 Nov 2016 11:58:12 -0800
"Alissa Cooper" <[e-mail]> wrote:

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


Hi Alissa,

thanks for reviewing the document! A few comments inline.


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


It does, thanks for the proposed text! Alia and Ben proposed some minor
revision to this in related comments, so I'll integrate the new text in
the next version.


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


Good point. Do you think adding some text like "A B2BUA SHOULD NOT
randomly drop or forward RTCP feedback of the same type within the
context of the same session, as that may lead to confusing, if not
broken, feedback to the recipients of the message." would help clarify
the consequences of such a behaviour? If you think it's worthwhile, I
might add as an example the RFC 7002 block one you presented.


> (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?
> 


You're right, I'll fix this.


> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> = Section 3.2 =
> 
> s/properly address/reflected/
> 


Thanks!
Lorenzo


> 
> _______________________________________________
> straw mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/straw