Subject: [AVT] AVT minutes at IETF 75 -- first draft

From: Tom Taylor <[email-masked]>
Date: Wed, 12 Aug 2009 14:28:03 -0400

AVT met Monday morning, 09:00-11:30, and Friday, 14:15-15:15. Chairs were Roni 
Even and Tom Taylor. Thanks to Bill ver Steeg, Colin Perkins, and Brian Rosen 
for your meeting notes.

1. Agenda and Note Well
    ====================

See http://www.ietf.org/proceedings/75/agenda/avt.html. The agenda was accepted 
as proposed, except for a note by Colin Perkins <[email-masked]> that the 
authors of the ECN-related documents agreed on a single common presentation on 
Friday afternoon.

2. Status
    ======

Roni Even reported. See http://www.ietf.org/proceedings/75/slides/avt-0.pdf. It 
was noted that a queue of drafts is building up behind draft-ietf-avt-rtcpssm, 
which awaits an editorial update. Colin Perkins promised that the update would 
be provided shortly.

Tom Taylor explained that he had mistakenly failed to copy the list when calling 
a halt to the debate over max-send-level in the 3984bis draft for lack of 
consensus. Actually the debate had continued behind the scenes, but Ye-Kui 
<[email-masked]> and Randell <[email-masked]> finally came to an 
agreement and updated text should be available shortly. We will have a second 
short WGLC on the revised text, then 3984bis and the SVC draft can proceed to 
the IESG.

The authors feel that draft-ietf-avt-rtp-gsm-hr will be ready for WGLC after 
another iteration.

3. Rapid Acquisition for Multicast RTP Sessions
    ============================================

draft-ietf-avt-rapid-acquisition-for-rtp-01.
Bill ver Steeg <[email-masked]> reported.
See http://www.ietf.org/proceedings/75/slides/avt-1.pdf.

The presentation listed a number of open issues. The one issue discussed in the 
meeting was the question Ye-Kui Wang raised on the list, about why the Min RAMS 
Buffer Fill Requirement AVP is needed in the RAMS Request message. Bill's reply 
was that the sender needs this information to know the minimum fill the receiver 
requires in its jitter buffer. (Or the receiver may have other buffer 
requirements.) Ye-Kui commented that this AVP might force the Retransmission 
Server to select an earlier I-frame start point for the beginning of the 
retransmitted burst, rather than the most recent one. Ali Begen 
<[email-masked]> expanded on Bill's answer, saying that there are lots of 
reasons why the receiver needs an increased buffer fill.  The server will have 
to decide on the right starting point depending on the requirements indicated by 
the receiver.  The server might even decide it is faster to wait for the next 
I-frame rather than go back.

Roni Even commented that the draft should discuss the issues that clients may 
have in setting the value of the Min RAMS Buffer Fill Requirement AVP.

The remaining open issues were referred to the list.

4. Port Mapping for Retransmission
    ===============================

No draft.
Roni Even reported.
See http://www.ietf.org/proceedings/75/slides/avt-2.pdf.

This issue came up in the work on rapid acquisition of multicast streams, but 
also applies to small-group multicast as described by RFC 4588. The basic 
problem is that declarative SDP (as opposed to offer-answer) does not allow the 
receiver of a unicast stream such as a retransmission stream within a multicast 
session to specify the transport address to which the stream should be sent.

Comments on the Problem Summary slide:

Dave Oran <[email-masked]> commented that the operation should be atomic to 
avoid the need for correlation of exchanged messages. Moreover, the mechanism 
has to finish before the retransmission starts, but not too early or we have NAT 
bindings expire, or maintain too much state at the sender (at worst, state for 
each receiver in a large multicast group).

Colin Perkins had an architectural concern with the transmission of transport 
addresses in RTCP. The alternative is perhaps to use STUN. Dave Oran pointed out 
that there is an atomicity issue with synchronization of STUN with the RTCP/RTP 
exchange. Moreover STUN has its own architectural issues, since it is designed 
for a stateless server and the retransmission server is stateful. Finally, 
whatever the solution, we must guard against reflection attacks.

It was agreed that the IP address to which the flow should be directed would 
always be that from which the RTCP FB or NACK message originated. However, the 
port would be different in general.

It was agreed that off-line discussion was needed. A meeting was arranged over 
the lunch hour on Tuesday. The report of the outcome of that meeting was 
presented on Friday afternoon (see below).

5. Synchronized Playback in RAMS
    =============================

draft-yang-avt-rtp-synced-playback-00.
Peilin Yang <[email-masked]> presented.
See http://www.ietf.org/proceedings/75/slides/avt-3.pdf.

Bill ver Steeg reported that Cisco is filing IPR statements in this area.

Ali Begen wondered how the server could set N and V, given that there are other 
sources of delay such as jitter that are specific to the receiver. He also 
pointed out that frame skipping does not account for the audio portion of the 
media transmission. Ashok Narayanan <> noted that speeding up and slowing down 
video will introduce artifacts.

Dave Oran and Colin Perkins made the point that synchronized playback to 
multiple receivers is a general problem, and a very difficult one. Ye-Kui 
countered that at least one component of delay could be removed by this 
technique. He cited work on delay reduction ongoing in TISPAN, involving 
real-time measurement of delay. Dave Oran asked on what scale: 2 receivers or 
200,000? It would appear the work is closer to 2. Dave suggested the problem 
could be larger in some network situations.

There was a comment that other methods were available for adjusting timing, each 
with its own quality issues. One part of the difficulty of the general problem 
is that delay across the Internet is variable.

Roni's summation was that there have been lots of comments to address, 
especially the factor of changing delay on the Internet.  The problem is 
interesting, but the solution presented may not be appropriate.

6. Improved Rapid Acquisition of Multicast Sessions
    ================================================

draft-wang-avt-rtp-improved-rams-00.
Ye-Kui Wang presented.
See http://www.ietf.org/proceedings/75/slides/avt-4.pdf.

Bill ver Steeg wondered if this was intended to be a new normative specification 
or implementation guidelines for the existing draft. Ali Begen suggested it was 
up to the receiver to choose the right time to join the multicast session. Colin 
Perkins was concerned that this might be over-specifying receiver behaviour. 
Ye-Kui responded that we have to be sure to specify behaviour adequately.

Further discussion focussed on the assumption that the bottleneck link was 
adjacent to the receiver (hence the receiver knows the bandwidth available). 
Ye-Kui suggested this was a reasonable assumption in the the case of a home 
network, where devices know the guaranteed bandwidth from the service provider 
and can be aware of bandwidth consumption by other devices in the home. Colin 
Perkins countered that devices must always be aware of congestion and loss and 
be prepared to back off.

7. Multicast Acquisition Report Block Type for RTCP XR
    ===================================================

draft-begen-avt-rapid-sync-rtcp-xr-01.
Ali Begen presented.
See http://www.ietf.org/proceedings/75/slides/avt-5.pdf.

Bill ver Steeg noted the need, here and elsewhere, to deal with extended 
sequence numbers.

8. Audio Level Indicators in RTP Streams
    =====================================

Combined presentation of draft-ivov-avt-slic-00 and 
draft-lennox-avt-rtp-audio-level-exthdr-00.
Enrico Marocco <[email-masked]> presented.
See http://www.ietf.org/proceedings/75/slides/avt-6.pdf.

The problem statement, draft-ivov-avt-slic-00, was worked up on the DISPATCH 
list. The problem was referred to AVT after a solution approach was selected. 
There are actually two related problems. draft-ivov-avt-slic-00 is concerned 
with getting audio levels from a mixer to a receiver. 
draft-lennox-avt-rtp-audio-level-exthdr-00 is concerned with getting audio 
levels from a sender to a mixer.

Jeffrey Goldberg <> suggested additional metadata besides audio volume (e.g. 
position, Dolby) might be interesting. Jonathan Lennox <[email-masked]> 
replied that this could be the subject of another header extension draft.

Francois Audet <[email-masked]> could see the reasoning for in-band transport 
of the indicators from the mixer to the receiver, but was concerned that in-band 
transport from the senders would involve a lot of code and drive up client cost. 
Enrico cited the need rapid responsiveness to changing speaker conditions. Roni 
Even expressed a concern about packet congestion, and Francois was concerned 
over compatibility with existing terminals.

Gunnar Hellstrom <[email-masked]> saw a possible use case for text 
conferencing (e.g. using RFC 4103), where the information presented would be the 
source of a particular text message.

Dave Oran had a thought: perhaps send comfort noise payload with the same 
timestamp as the primary packets. [Not clear if this was related to Gunnar's use 
case.] Jonathan Lennox suggested that RED (RFC 2198) would be less heavyweight.

9. SRTP Store-and-Forward
    ======================

draft-mattsson-srtp-store-and-forward-03 and draft-naslund-srtp-saf-02.
John Mattsson <[email-masked]> presented.
See http://www.ietf.org/proceedings/75/slides/avt-7.pdf.

Cullen Jennings <[email-masked]> asked what has changed since the last 
meeting. Were the objections raised in that meeting addressed? The answer was 
that the usage of CCI and CID has changed. Richard Barnes <[email-masked]> 
asked if CCI and CID are protected. John said they were not -- they were like 
PKI in SRTP.

Roni noted a list comment. Dan Wing could not be present because of a collision 
with BEHAVE, but felt that the solution was complicated both on the client and 
on the server. John said it wasn't really -- they had implemented it in two days.

Randell Jesup commented offline that the RTCP part wasn't mentioned in the 
draft. RTCP is needed in some cases to sort out data misordering. John stated 
that the middlebox has to store the relevant part of the RTCP. The RTCP does not 
need protection.

Cullen asked how many had read the draft. A few had done so. Given that most 
people who needed to comment were absent, further discussion was deferred to the 
list.

===========================================================================
===========================================================================

Friday presentations. Thanks to Dave Oran for the notes.

1. Agenda and Note Well
    ====================

Roni Even opened the meeting.
See http://www.ietf.org/proceedings/75/slides/avt-8.pdf.

A report from Tuesday's port mapping breakout session was added as the last item 
on the agenda.

2. ECN for RTP over UDP/IP
    =======================

draft-westerlund-avt-ecn-for-rtp-00.txt 
draft-carlberg-avt-rtp-ecn-02.txt 
draft-carlberg-avt-rtcp-xr-ecn-01.txt
Piers O'Hanlon <[email-masked]> presented.
See http://www.ietf.org/proceedings/75/slides/avt-11.pdf.

Chart 2:
ECN is actually quite useful to realtime flow - can adapt before loss occurs. 
(TCP can retransmit.) Most RTP flows today do not adapt to loss - using loss as 
a signal can be too late to recover before playout deadline expires.

Chart 3:
Newer codecs can do rate adaptation.
ECN allows really congestion response and better user experience (but this draft 
does not specify the sender's reaction to feedback).

Chart 4:
ECN-for-TCP tutorial.

Chart 5:
Extension to UDP seems straightforward:
     - Signal ECN using SDP offer/answer
     - set ECT on RTP data packets
     - send feedback on RTCP RRs (no portable way to monitor receiver ECN marks 
on UDP).

Chart 6:
Actually not quite that simple
     - need to tell if media path supports ECN - can't do this on signaling path
     - current AVPF is slow - many RTTs.
     - frequent rate changes are not good for user experience.
Unlikely it will be strictly TCP-friendly.

Charts 7-8:
     - RTP has mixers and translators - explicit middle-boxes
     - mixers are the easy case since they are endpoints.
     - multicast complicates picture.
Basic message: ECN capability varies across receivers and along paths.

Chart 9:
Here is a proposal. Four components
     - negotiate with SDP offer/answer
     - verification of the media path capability to ECN
     - feedback
     - error control, fallback.
     - broken middle boxes can drop/remark packets
     - need to probe the path. Two ways.
1. use ICE & STUN (details to be sorted out)
2. treat ICE as optimization, but do RTP-native probe.

Bob  Briscoe <[email-masked]>: may have an alternative for how to do 
the data path operations. One can simplify by only doing data plane probing - no 
need for negotiation.
Colin Perkins: reason to have the negotiation is to avoid problems with boxes 
not prepared to receive RTCP packets they don't understand.

Chart 9 (cont'd)
     - need to monitor in case path fails
     - can do receiver-only adaptation, but much better to always send feedback.

Complications:
- translators that don't change the media are easy
- it's the ones that split/join you need to be careful about
- media transcoders are harder - need to separate the legs.

The authors suggested that this be joint work with TSVAREA, but adopt it as an 
AVT work item. They were instructed to submit a joint draft. The chairs will 
discuss how and if to add a WG charter item for this work.

3. RTP Payload Format for MPEG2-TS Preamble
    ========================================

draft-begen-avt-rtp-mpeg2ts-preamble-01
Ali Begen presented.
See http://www.ietf.org/proceedings/75/slides/avt-9.pdf.

The proposed payload format carries MPEG2-TS (transport stream) stuff, but not 
what RFC2250 does.
Question: are the parts in this payload scattered in the transport stream? 
Answer: yes.

The encoder locks onto the "TSRAP" (Transport stream random access point).
- extracts the needed pieces from the TS, and sends them in RTP.
- encodes via TLVs like in RAMS: examples - PAT, PMT, PCR, SEQ, ECM, EMM.
Question: how does the canonical order for feeding to the decoder interact with 
the encoding order in the payload packets?
Question: do we really need vendor extensibility? Answer: yes.

4.Multicast/Unicast Port Mapping Proposal
   =======================================

No draft.
Roni Even presented.
See http://www.ietf.org/proceedings/75/slides/avt-10.pdf.

Tuesday's breakout session discussed how to deal with the port assignment 
problem. They came up with a strawman proposal which the group believes solves 
the problem:
- do a two-phase operation
- first phase to get port information to the server, server turns this into a 
cookie and replies to the client.
This can be done in advance, doesn't store server state, and avoids reflection 
attacks.
- at the time you need to do the real transaction (e.g. NAK, RAMS), send the 
cookie by which the server can figure out the ports to use for the outbound 
packets (both RTP and RTCP).

Next step is to prepare a draft based on this.
Do we need a charter change? do we need a milestone?
Does WG think it's suitable?

Hum taken - no hums against, some hums in favor.

---

From: Colin Perkins <[email-masked]>
Date: Wed, 12 Aug 2009 21:55:22 +0100

On 12 Aug 2009, at 19:28, Tom Taylor wrote:
> AVT met Monday morning, 09:00-11:30, and Friday, 14:15-15:15. Chairs  
> were Roni Even and Tom Taylor. Thanks to Bill ver Steeg, Colin  
> Perkins, and Brian Rosen for your meeting notes.
>
> 1. Agenda and Note Well
>   ====================
>
> See http://www.ietf.org/proceedings/75/agenda/avt.html. The agenda  
> was accepted as proposed, except for a note by Colin Perkins <[email-masked] 
> > that the authors of the ECN-related documents agreed on a single  
> common presentation on Friday afternoon.
>
> 2. Status
>   ======
>
> Roni Even reported. See http://www.ietf.org/proceedings/75/slides/avt-0.pdf 
> . It was noted that a queue of drafts is building up behind draft- 
> ietf-avt-rtcpssm, which awaits an editorial update. Colin Perkins  
> promised that the update would be provided shortly.

One minor correction: Jörg promised me that an update would be  
provided shortly; I'm not going to provide the update (indeed, some of  
my drafts are blocked waiting for it...)

> Tom Taylor explained that he had mistakenly failed to copy the list  
> when calling a halt to the debate over max-send-level in the 3984bis  
> draft for lack of consensus. Actually the debate had continued  
> behind the scenes, but Ye-Kui <[email-masked]> and Randell <[email-masked] 
> > finally came to an agreement and updated text should be available  
> shortly. We will have a second short WGLC on the revised text, then  
> 3984bis and the SVC draft can proceed to the IESG.
>
> The authors feel that draft-ietf-avt-rtp-gsm-hr will be ready for  
> WGLC after another iteration.
>
> The presentation listed a number of open issues. The one issue  
> discussed in the meeting was the question Ye-Kui Wang raised on the  
> list, about why the Min RAMS Buffer Fill Requirement AVP is needed  
> in the RAMS Request message. Bill's reply was that the sender needs  
> this information to know the minimum fill the receiver requires in  
> its jitter buffer. (Or the receiver may have other buffer  
> requirements.) Ye-Kui commented that this AVP might force the  
> Retransmission Server to select an earlier I-frame start point for  
> the beginning of the retransmitted burst, rather than the most  
> recent one. Ali Begen <[email-masked]> expanded on Bill's answer,  
> saying that there are lots of reasons why the receiver needs an  
> increased buffer fill.  The server will have to decide on the right  
> starting point depending on the requirements indicated by the  
> receiver.  The server might even decide it is faster to wait for the  
> next I-frame rather than go back.
>
> Roni Even commented that the draft should discuss the issues that  
> clients may have in setting the value of the Min RAMS Buffer Fill  
> Requirement AVP.
>
> This issue came up in the work on rapid acquisition of multicast  
> streams, but also applies to small-group multicast as described by  
> RFC 4588. The basic problem is that declarative SDP (as opposed to  
> offer-answer) does not allow the receiver of a unicast stream such  
> as a retransmission stream within a multicast session to specify the  
> transport address to which the stream should be sent.
>
> Dave Oran <[email-masked]> commented that the operation should be  
> atomic to avoid the need for correlation of exchanged messages.  
> Moreover, the mechanism has to finish before the retransmission  
> starts, but not too early or we have NAT bindings expire, or  
> maintain too much state at the sender (at worst, state for each  
> receiver in a large multicast group).
>
> Colin Perkins had an architectural concern with the transmission of  
> transport addresses in RTCP. The alternative is perhaps to use STUN.  
> Dave Oran pointed out that there is an atomicity issue with  
> synchronization of STUN with the RTCP/RTP exchange. Moreover STUN  
> has its own architectural issues, since it is designed for a  
> stateless server and the retransmission server is stateful. Finally,  
> It was agreed that the IP address to which the flow should be  
> directed would always be that from which the RTCP FB or NACK message  
> originated. However, the port would be different in general.
>
> It was agreed that off-line discussion was needed. A meeting was  
> arranged over the lunch hour on Tuesday. The report of the outcome  
> of that meeting was presented on Friday afternoon (see below).
>
> Ali Begen wondered how the server could set N and V, given that  
> there are other sources of delay such as jitter that are specific to  
> the receiver. He also pointed out that frame skipping does not  
> account for the audio portion of the media transmission. Ashok  
> Narayanan <> noted that speeding up and slowing down video will  
> introduce artifacts.
>
> Dave Oran and Colin Perkins made the point that synchronized  
> playback to multiple receivers is a general problem, and a very  
> difficult one. Ye-Kui countered that at least one component of delay  
> could be removed by this technique. He cited work on delay reduction  
> ongoing in TISPAN, involving real-time measurement of delay. Dave  
> Oran asked on what scale: 2 receivers or 200,000? It would appear  
> the work is closer to 2. Dave suggested the problem could be larger  
> in some network situations.
>
> There was a comment that other methods were available for adjusting  
> timing, each with its own quality issues. One part of the difficulty  
> of the general problem is that delay across the Internet is variable.
>
> Roni's summation was that there have been lots of comments to  
> address, especially the factor of changing delay on the Internet.   
> The problem is interesting, but the solution presented may not be  
> appropriate.
>
> Bill ver Steeg wondered if this was intended to be a new normative  
> specification or implementation guidelines for the existing draft.  
> Ali Begen suggested it was up to the receiver to choose the right  
> time to join the multicast session. Colin Perkins was concerned that  
> this might be over-specifying receiver behaviour. Ye-Kui responded  
> that we have to be sure to specify behaviour adequately.
>
> Further discussion focussed on the assumption that the bottleneck  
> link was adjacent to the receiver (hence the receiver knows the  
> bandwidth available). Ye-Kui suggested this was a reasonable  
> assumption in the the case of a home network, where devices know the  
> guaranteed bandwidth from the service provider and can be aware of  
> bandwidth consumption by other devices in the home. Colin Perkins  
> countered that devices must always be aware of congestion and loss  
> and be prepared to back off.
>
> Bill ver Steeg noted the need, here and elsewhere, to deal with  
> extended sequence numbers.
>
> Combined presentation of draft-ivov-avt-slic-00 and draft-lennox-avt- 
> rtp-audio-level-exthdr-00.
> The problem statement, draft-ivov-avt-slic-00, was worked up on the  
> DISPATCH list. The problem was referred to AVT after a solution  
> approach was selected. There are actually two related problems.  
> draft-ivov-avt-slic-00 is concerned with getting audio levels from a  
> mixer to a receiver. draft-lennox-avt-rtp-audio-level-exthdr-00 is  
> concerned with getting audio levels from a sender to a mixer.
>
> Jeffrey Goldberg <> suggested additional metadata besides audio  
> volume (e.g. position, Dolby) might be interesting. Jonathan Lennox <[email-masked] 
> Francois Audet <[email-masked]> could see the reasoning for in- 
> band transport of the indicators from the mixer to the receiver, but  
> was concerned that in-band transport from the senders would involve  
> a lot of code and drive up client cost. Enrico cited the need rapid  
> responsiveness to changing speaker conditions. Roni Even expressed a  
> concern about packet congestion, and Francois was concerned over  
> compatibility with existing terminals.
>
> Gunnar Hellstrom <[email-masked]> saw a possible use  
> case for text conferencing (e.g. using RFC 4103), where the  
> information presented would be the source of a particular text  
> message.
>
> Dave Oran had a thought: perhaps send comfort noise payload with the  
> same timestamp as the primary packets. [Not clear if this was  
> related to Gunnar's use case.] Jonathan Lennox suggested that RED  
> (RFC 2198) would be less heavyweight.
>
> Cullen Jennings <[email-masked]> asked what has changed since the  
> last meeting. Were the objections raised in that meeting addressed?  
> The answer was that the usage of CCI and CID has changed. Richard  
> Barnes <[email-masked]> asked if CCI and CID are protected. John  
> said they were not -- they were like PKI in SRTP.
>
> Roni noted a list comment. Dan Wing could not be present because of  
> a collision with BEHAVE, but felt that the solution was complicated  
> both on the client and on the server. John said it wasn't really --  
> they had implemented it in two days.
>
> Randell Jesup commented offline that the RTCP part wasn't mentioned  
> in the draft. RTCP is needed in some cases to sort out data  
> misordering. John stated that the middlebox has to store the  
> relevant part of the RTCP. The RTCP does not need protection.
>
> Cullen asked how many had read the draft. A few had done so. Given  
> that most people who needed to comment were absent, further  
> discussion was deferred to the list.
>
> = 
> = 
> = 
> = 
> = 
> ======================================================================
> = 
> = 
> = 
> = 
> = 
> ======================================================================
>
> A report from Tuesday's port mapping breakout session was added as  
> the last item on the agenda.
>
> draft-westerlund-avt-ecn-for-rtp-00.txt draft-carlberg-avt-rtp- 
> ecn-02.txt draft-carlberg-avt-rtcp-xr-ecn-01.txt
> ECN is actually quite useful to realtime flow - can adapt before  
> loss occurs. (TCP can retransmit.) Most RTP flows today do not adapt  
> to loss - using loss as a signal can be too late to recover before  
> playout deadline expires.
>
> Chart 3:
> ECN allows really congestion response and better user experience  
> (but this draft does not specify the sender's reaction to feedback).
>
> Chart 4:
> ECN-for-TCP tutorial.
>
> Chart 5:
>    - send feedback on RTCP RRs (no portable way to monitor receiver  
> ECN marks on UDP).
>
> Chart 6:
> Bob  Briscoe <[email-masked]>: may have an alternative for  
> how to do the data path operations. One can simplify by only doing  
> data plane probing - no need for negotiation.
> Colin Perkins: reason to have the negotiation is to avoid problems  
> with boxes not prepared to receive RTCP packets they don't understand.
>
> Chart 9 (cont'd)
> The authors suggested that this be joint work with TSVAREA, but  
> adopt it as an AVT work item. They were instructed to submit a joint  
> draft. The chairs will discuss how and if to add a WG charter item  
> for this work.
>
> The proposed payload format carries MPEG2-TS (transport stream)  
> stuff, but not what RFC2250 does.
> Question: are the parts in this payload scattered in the transport  
> stream? Answer: yes.
>
> Question: how does the canonical order for feeding to the decoder  
> interact with the encoding order in the payload packets?
> Tuesday's breakout session discussed how to deal with the port  
> assignment problem. They came up with a strawman proposal which the  
> group believes solves the problem:
> - first phase to get port information to the server, server turns  
> this into a cookie and replies to the client.
> This can be done in advance, doesn't store server state, and avoids  
> reflection attacks.
> - at the time you need to do the real transaction (e.g. NAK, RAMS),  
> send the cookie by which the server can figure out the ports to use  
> for the outbound packets (both RTP and RTCP).
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Colin Perkins
http://csperkins.org/

---

From: Rolf Blom <[email-masked]>
Date: Thu, 13 Aug 2009 09:39:47 +0200

Hi Tom,

A correction in 9 SRTP Store and Forward  first paragraph last sentence:  

John said they were not -- they were like MKI in SRTP.

/Rolf
> Barnes <[email-masked]> asked if CCI and CID are protected. John said 
> they were not -- they were like PKI in SRTP.
>
> Roni noted a list comment. Dan Wing could not be present because of a 
> collision with BEHAVE, but felt that the solution was complicated both 
> on the client and on the server. John said it wasn't really -- they 
> had implemented it in two days.
>
> Randell Jesup commented offline that the RTCP part wasn't mentioned in 
> the draft. RTCP is needed in some cases to sort out data misordering. 
> John stated that the middlebox has to store the relevant part of the 
> RTCP. The RTCP does not need protection.
>
> that most people who needed to comment were absent, further discussion 
> was deferred to the list.

---

From: Tom Taylor <[email-masked]>
Date: Thu, 13 Aug 2009 08:43:29 -0400

Thnaks, this and Colins are fixed. I'll upload a new version of the minutes to 
Datatracker at the end of the day.

>> 9. SRTP Store-and-Forward
...