The IETF 85 meeting was held from November 4-9, 2012 in Atlanta, GA, USA
- Magnus Westerlund and Colin Perkins, Multiple RTP Session on a Single Lower-Layer Transport (.txt|.pdf), Internet Engineering Task Force, October 2012, Work in progress (draft-westerlund-avtcore-transport-multiplexing-04.txt).
The main changes in this version are:
- Make the prefix-based shim the preferred solution, following the discussions at IETF 84 and elsewhere. Define the shim as being two octets with a 14-bit session ID, and 2-bits to avoid clashes with other protocols.
- Clarify that the prefix needs to be chosen to avoid clashes with any STUN or DTLS packets multiplexed on the same port.
- Note that the signalling is waiting on the outcome of the BUNDLE discussions in the IETF MMUSIC working group.
- Note that DTLS-SRTP and MIKEY key derivation might need to be updated to avoid having to derive new keys for each multiplexed session. Details are to-be-determined.
- Colin Perkins, Magnus Westerlund, and Jörg Ott, Web Real-Time Communication (WebRTC): Media Transport and Use of RTP (.txt|.pdf), Internet Engineering Task Force, October 2012, Work in progress (draft-ietf-rtcweb-rtp-usage-05.txt).
The changes in this version of the draft are as follows:
- Use RFC 2119 terminology by reference, rather than by copying the definitions.
- In Section 4.2 on the Choice of RTP Profile, note that the RTP/SAVPF profile with the updated list of recommended codecs is mandated, not the standard RTP/SAVPF profile. Update Section 4.3 on the Choice of RTP Payload Formats to match.
- In Section 4.6, clarify that the use of non-compound RTCP packets MUST be negotiated on the signalling channel before use, and that implementations are REQUIRED to support compound RTCP feedback packets if the remote endpoint does not agree to use non-compound RTCP packets.
- In Section 4.9, remove the reference to RFC 6222 and instead reference the RFC 622bis draft.
- Update references to RFC 5117 to joint to the RTP Topologies update draft.
- In Section 5.1.1, clarify that a WebRTC sender is REQUIRED to understand and react to FIR messages it receives, but that sending FIR messages is OPTIONAL.
- Rewrite Section 7 on rate control and media adaptation for clarity. Merge the previous Sections 7.1 and 7.2 into a single new section, and try to better explain the relationship between the RTP circuit breakers, the signalled SDP bandwidth limitations, and any RTP/AVPF TMMBR messages.
- Add Section 13 on Open Issues.
- Revise and expand Section 15 on Security Considerations.
- Magnus Westerlund and Colin Perkins, Options for Securing RTP Sessions (.txt|.pdf), Internet Engineering Task Force, October 2012, Work in progress (draft-ietf-avtcore-rtp-security-options-01.txt).
Minor editorial updates. Clarify that using an unpredictably chosen CNAME might be helpful for privacy.
- Colin Perkins and Varun Singh, RTP Congestion Control: Circuit Breakers for Unicast Sessions (.txt|.pdf), Internet Engineering Task Force, October 2012, Work in progress (draft-ietf-avtcore-rtp-circuit-breakers-01.txt).
The changes in this version are as follows:
- Clarify that multicast congestion control is outside the scope of this memo.
- Clarify what it means for an implementation to cease transmission when the circuit breaker fires. Specifically, the intention is that the application will stop sending RTP data packets until the user makes an explicit attempt to restart the call. The draft notes that RTP flows halted by the circuit breaker should not be restarted automatically unless the sender has received information that the congestion has dissipated.
- Add an explicit RTCP Timeout circuit breaker in Section 4.2 (this is a revised and extended version of Section 8 of the -00 draft"> Unlike the media timeout in Section 4.1, which fires when returning RTCP RR packets show that media isn't reaching the receiver, this circuit breaker is triggered if RTCP packets are no longer returning to the sender.
- In section 4.3, clarify when high-rate senders can back-off to a lower rate when the circuit breaker is triggered, and when they need to cease transmission.
- Expand and clarify Section 5 about RTP circuit breakers for systems using the RTP/AVPF profile. A sender needs to process early RTCP reports that contain an SR/RR packet as-if they were regular RTCP reports, but ignore early non-compound RTCP packets without an SR/RR. This allows the use of low-overhead early RTP/AVPF feedback without triggering the RTP circuit breaker, and so is suitable for RTP congestion control algorithms that need to quickly report loss events in between regular RTCP reports.
- Expand and clarify Section 6 about the impact of RTCP XR, to note that RTCP XR packets are ignored by the circuit breaker algorithm.
- Expand and clarify Section 7 about the impact of ECN, to note that reports of ECN-CE marks are treated as packet loss for the congestion based circuit breaker, but ignored for the media timeout and RTCP timeout circuit breakers.
- Expand and clarify Section 8 on the security considerations to discuss authentication requirements.
- Colin Perkins and Varun Singh, RTP Congestion Control: Circuit Breakers for Unicast Sessions (.txt|.pdf), Internet Engineering Task Force, October 2012, Work in progress (draft-ietf-avtcore-rtp-circuit-breakers-00.txt).
Our draft on circuit breakers for RTP congestion control was adopted as an AVTCORE working group draft at IETF 84 in Vancouver. This version is submitted to reflect this change in status. The content is identical to the previous individual submission.
- Magnus Westerlund, Colin Perkins, and Jonathan Lennox, Multiple Media Types in an RTP Session (.txt|.pdf), Internet Engineering Task Force, October 2012, Work in progress (draft-ietf-avtcore-multi-media-rtp-session-01.txt).
This version makes the following changes:
- Note that RFC 3551 mandates that audio and video are run on separate RTP sessions, and so needs to be updated if we are to allow multiple media types in a single RTP session. Section 6.1 is updated to specify this.
- Update Section 3.3, to clarify what is meant by architectural equality. In particular, note that RTP requires a common session bandwidth, so any flows that are multiplexed together in an RTP session need to have similar bandwidth requirements.
- Update Section 5.1 to further clarify that all flows that are to be multiplexed together need to have similar bandwidth requirements, due to the requirement for a common RTCP reporting interval.
- Update Sections 6.3 and 7.2 to clarify use with the RTP payload format for Generic FEC.
- Update Section 6.4 to discuss the constraints imposed by the single RTCP reporting interval.
- Magnus Westerlund, Colin Perkins, and Jonathan Lennox, Multiple Media Types in an RTP Session (.txt|.pdf), Internet Engineering Task Force, October 2012, Work in progress (draft-ietf-avtcore-multi-media-rtp-session-00.txt).
Our draft on Multiple Media Types in an RTP Session was adopted as a work item of the IETF AVTCORE working group during the IETF 84 meeting in Vancouver in July 2012. The -00 working group draft brings the references up-to-date, but is otherwise identical to the last individual submission.
- Colin Perkins and Magnus Westerlund, Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution (.txt|.pdf), Internet Engineering Task Force, October 2012, Work in progress (draft-ietf-avt-srtp-not-mandatory-10.txt).
Add reference to ISMAcryp. Rewrite Conclusions section.