Guidelines for End-to-End Support of the RTP Control Protocol (RTCP) in Back-to-Back User Agents (B2BUAs)
draft-ietf-straw-b2bua-rtcp-17

[Ballot comment]

Thanks for handling my discuss point. Sorry for being a
bit slow in clearing that.

- The security considerations section is (still!) pretty good,
thanks!

[Ballot comment]
Two points were raised by Russ Housley's Gen-ART review. On the first one, I plan to watch the resolution of the Discusses related to the unclear SHOULD NOT. (It certainly would have been a Discuss from me if a Discuss wasn’t already raised.) On the second point regarding the document class, I have noted the issue but don't plan on block document based on it. Looking forward to further discussion if people want to argue it.

[Ballot comment]
Thanks for responding to Magnus's thorough TSV-ART review (for reference, https://www.ietf.org/mail-archive/web/tsv-art/current/msg00111.html).

I'm inclined to agree with the resolutions you've proposed (for reference, https://www.ietf.org/mail-archive/web/tsv-art/current/msg00112.html), but I do have one question - given that you want to include REMB, because it's deployed in Chrome and Firefox, and given that https://datatracker.ietf.org/doc/draft-alvestrand-rmcat-remb/ hasn't moved in three years and RMCAT is doing something else, what's your plan for publishing this draft as an RFC that's not stuck in MISSREF forever?

[Ballot comment]
I agree with Alissa that the set of attributes that fall into each category is just not clear or fully specified.
I'm not sure about better wording - but at least indicating how to categorize the different attributes (if listing them
all isn't reasonable) would help.  Describing the category as "those that cause issues"' is not helpful.

[Ballot 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?

[Ballot comment]
[1] As I understand it, a Media-Aware Relay is an instance of a RTP/RTCP translator.  I'm wondering whether the behavior in 3.2 can/should be more broadly applied to other types of translators, and not just to a media-aware B2BUA.  ??  [Disclaimer:  I am out of my depth here...]

[2] The guidelines in 3.2 have a normative "MUST" attached to them: "...a media-aware B2BUA MUST handle incoming RTCP messages to forward following this guideline".  However, some of the references are not Normative.  I assume that (as with the guidelines related to RFC3550) the text in 3.2 represents a behavior beyond what is described in the references, which implies to me that those references should be Normative.  The solution seems simple: move rfc3611, rfc5104, etc. to be Normative references...but I-D.alvestrand-rmcat-remb is also referenced, which not only expired 3 years ago, but it is marked as Experimental.  Can the expected behavior from I-D.alvestrand-rmcat-remb be somehow defined in this document so that the reference is not needed?

[Ballot discuss]

intro: Including the LI example in section 1 seems
wrong given RFC2804. And I don't see why you need it if
there are other justifications that are not controversial
in the IETF. Why not just delete that? (The problem with
including that justification in a standards track document
is that doing so goes entirely against RFC2804.)

But this should be an easy fix, via a revised ID or RFC
editor note.

[Ballot comment]
High level comment:
This document mainly talks about cases where the SSRC or the RTP seq# is changed. Are they no other fields that could be changed as well? Would there need to be additional guidance (in 3.2) then, or are SSRC and seq# more special then other fields? And why would a relay change those fields? Wouldn't it be appropriate to give the guidance somewhere that those fields SHOULD NOT be changed!?!

Smaller comments:

section 3.1:
"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."
Shouldn't that be a MUST (with all the exceptions given already)...?

"...a B2BUA MAY rewrite CNAME items if any potential collision
  is detected..."
And why is that a MAY? Shouldn't this be a SHOULD at least?

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-straw-b2bua-rtcp-13.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: ben@nostrum.com, straw@ietf.org, christer.holmberg@ericsson.com, draft-ietf-straw-b2bua-rtcp@ietf.org, straw-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Guidelines to support RTCP end-to-end in Back-to-Back User Agents (B2BUAs)) to Proposed Standard


The IESG has received a request from the Sip Traversal Required for
Applications to Work WG (straw) to consider the following document:
- 'Guidelines to support RTCP end-to-end in Back-to-Back User Agents
  (B2BUAs)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-10-10. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  SIP Back-to-Back User Agents (B2BUAs) are often envisaged to also be
  on the media path, rather than just intercepting signalling.  This
  means that B2BUAs often implement an RTP/RTCP stack as well, thus
  leading to separate multimedia sessions that the B2BUA correlates and
  bridges together.  If not disciplined, though, this behaviour can
  severely impact the communication experience, especially when
  statistics and feedback information contained in RTCP messages get
  lost because of mismatches in the reported data.

  This document defines the proper behaviour B2BUAs should follow when
  also acting on the signalling/media plane in order to preserve the
  end-to-end functionality of RTCP.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7656: A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources (Informational - IETF stream)
Note that some of these references may already be listed in the acceptable Downref Registry.

his is my AD Evaluation of draft-ietf-straw-b2bua-rtcp.

In summary, I don't think this draft is ready for IETF last call. There are sections where the language is really hard to follow. It needs another editing/rewriting pass, focusing on language clarity. This is especially true from the middle of section 3.2 on. For this reason, I am moving the draft to the "AD Is Watching" state.

Other comments:

-- 1, 2nd paragraph, last 2 sentences:

5117 will be obsoleted by the topologies update draft soon. I suggest you just reference that one.

-- 2, 2nd paragraph

The reference to grouping-taxonomy may need to be normative, since it is referenced for terminology. If that terminology is needed to understand this draft, then it needs to be normative. I think this case is actually borderline, but you can expect other ADs to bring it up at the telechat. If you can reasonably argue that the reference doesn't need to be normative, that's fine--but be prepared to do so.

(This needs to be addressed one way or the other prior to IETF last call, since any normative downref would need to be listed in the last call announcement.)

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

Intended status: Standards Track

Why is this the proper type of RFC?

The document contains normative procedures.

Is this type of RFC indicated in the title page header?

Yes

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:
Technical Summary:
Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

SIP Back-to-Back User Agents (B2BUAs) are often envisaged to also be on the media path, rather than just intercepting signalling. This means that B2BUAs often implement an RTP/RTCP stack as well, whether to act as media transcoders or to just passthrough the media themselves, thus leading to separate multimedia sessions that the B2BUA correlates and bridges together. If not disciplined, though, this behaviour can severely impact the communication experience, especially when statistics and feedback information contained in RTCP packets get lost because of mismatches in the reported data.
This document defines the proper behaviour B2BUAs should follow when also acting on the signalling/media plane in order to preserve the end-to-end functionality of RTCP.

Working Group Summary:
Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

The WG path of this document was reasonably short and efficient. Several technical comments were made during reviews and all were resolved with consensus.
There is consensus in the STRAW WG to publish this document.

Document Quality:
Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

The guidelines and procedures in the document is based on input and experience from the implementer community.

Personnel:
Who is the Document Shepherd?

Christer Holmberg (christer.holmberg@ericsson.com -- STRAW WG co-chair)

Who is the Responsible Area Director?

Ben Campbell

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document is ready for publication

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The WG as a whole understand and agree with it

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

idnits 2.13.02

tmp/draft-ietf-straw-b2bua-rtcp-07.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document date (April 21, 2015) is 20 days in the past.  Is this
    intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

    No issues found here.

    Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).

    Run idnits with the --verbose option for more detailed information about
    the items above.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

Not Applicable

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

This document makes no request or reference to IANA

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

This document makes no request to IANA

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

This document does not use formal language such as XML code, BNF rules or MIB definitions.