Hello, I have reviewed this document as part of the security directorate’s ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Ready with nits The document defines the proper behavior for B2BUAs that, in addition to being on-path for SIP, are also on-path for the media traffic, whether RTP or RTCP. Section 3 describes different scenarios for B2BUAs operating on the media, and if features considerations of the type “if you change this, you also have to change that, otherwise this bad thing could happen.” The document is easy to read and understandable even to someone who is not well versed in SIP terminology. The security considerations section claims that the considerations are similar to those of the standards documents such as RFC 7667 (RTP topologies) and RFC 7656 (A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources). This seems reasonable. It also describes why encryption is not an issue (if the B2BUA can make some changes to the media stream, then it can also make the changes described in this document, otherwise, it can’t make the original changes either), and how failing to follow this document might be indistinguishable from an attack (that’s the “bad things happen” part) Two nits: - The Abstract says: “[B2BUAs] are often envisaged to also be on the media path...This means that B2BUAs often implement an RTP/RTCP stack...”. That doesn’t make sense with the dictionary definition of “envisage”. Perhaps “designed”? - The first paragraph of the Security Considerations is pasted below. I don’t think there is much semantic difference between "considerations" and “aspects”. This paragraph denies that there are considerations, and then goes on to state some. I think the whole first paragraph can go. Yoav