Subject: Re: [AVT] NewVersion: draft-versteeg-avt-rapid-synchronization-for-rtp-02

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Wed, 11 Mar 2009 12:29:19 -0400

Yes, the intent is for an open technical session. We are coordinating schedules of the existing contributors, and will have a suggested time. It is looking like monday, maybe tuesday. We will let you know. 

Bvs

----- Original Message -----
From: Roni Even <[email-masked]>
To: Bill Ver Steeg (versteb); 'Ye-Kui Wang' <[email-masked]>; Ali C. Begen (abegen); 'IETF AVT WG' <[email-masked]>
Cc: Dave Oran (oran)
Sent: Wed Mar 11 12:10:54 2009
Subject: RE: [AVT]	NewVersion:	draft-versteeg-avt-rapid-synchronization-for-rtp-02

Bill,
I hope that this breakout session is open, in this case I would suggest that
you will give people a couple of optional time slots to select.
Regards
Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bill
Ver Steeg (versteb)
Sent: Wednesday, March 11, 2009 5:46 PM
To: Ye-Kui Wang; Ali C. Begen (abegen); IETF AVT WG
Subject: Re: [AVT] NewVersion:
draft-versteeg-avt-rapid-synchronization-for-rtp-02

Ye-Kui Wang-

Thanks for your detailed review of the draft. We will be setting up
break-out session during the next IETF meeting to refine this draft. If
you are attending IETF, we would also like to have your input during
that break out session. We will be posting a meeting notice 

In-line comments, bracketed by "bvs"- 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ye-Kui Wang
Sent: Tuesday, March 10, 2009 1:31 AM
To: Ali C. Begen (abegen); 'IETF AVT WG'
Subject: Re: [AVT] NewVersion:
draft-versteeg-avt-rapid-synchronization-for-rtp-02

Hi Ali, All,

Some comments (text or just section number goes first, the corresponding
comment follows). 

[start]

   Section 1.
   In some other cases, the Reference Information is not
   contiguous in the flow but dispersed over a large period, which
   forces the receiver to wait for all of the Reference Information to
   arrive before starting to process the rest of the data.

Could you please give an example of dispersed Reference Information? Are
there any benefits for dispersing Reference Information. The drawback is
clear; it introduces additional delay for tuning-in. 

---bvs --- The initial design motivation for this draft was RTP
encapsulated MPEG2TS audio/video flows. In these flows, the largest item
of "reference information" is the I-frame. There is other reference
material distributed throughout the payload, including PAT/PMT/CAT and
ECMs. In DSMCC data carousels, there is also a lot of structure at the
"beginning of the file structure". Legacy (often proprietary) command
and control protocols often have authentication and scoping information
sprinkled dropout the data flow.

   Section 1.
   It is also worth noting that in order to issue
   the initial RTCP message to the feedback target, the SSRC of the
   session to be joined must be known prior to any packet reception, and
   hence, needs to be signaled out-of-band (or in-band). 

Shouldn't "(or in-band)" be removed, as in-band signaling of SSRC seems
impossible anyway, since upon joining a new session the receiver has
never received a packet?
---bvs --- agreed. "In-band" is an over-loaded term that has different
meaning in different contexts. We should strike in-band.
 
   Section 5.
   In particular, the system needs operate within a number of
constraints.

"needs operate" -> "needs to operate".
---bvs ---- agreed

   Fig. 2.
   
The arrow for the unicast RTP flow from RS to router is missing.

   Fig. 3.

"RMR-R" -> "RMS-R" 
"RMR-T"-> "RMS-T"

---bvs --- will fix

   Section 6.2, step 1. 
       Also note that since no RTP packets have been received yet for
this
       session, the SSRC must be obtained out-of-band or in-band.

Same as above, "or in-band" should be removed.

---bvs --- will fix

   Section 6.2, step 2. 
       If RR receives a message indicating that its rapid
synchronization
       request has been denied, it abandons the rapid synchronization
       attempt and MAY immediately join the multicast session by sending
       an IGMP Join message [RFC3376] to its upstream multicast router
       for the new multicast session.
 
Why "MAY", instead of "MUST" or "SHOULD", is used here?

---bvs --- The behavior is totally up to the desire of the client. I can
think of quite a few cases where the client would rather join another
stream (or no stream). If the information is stale after a second or
two, the receiver would not want to receive it. The user was "channel
surfing" and had gone on to another channel, etc. It MAY want to tune to
this stream, or it MAY want to tune to another stream, or it MAY want to
do nothing.

   Section 6.2, step 2. 
       If RS accepts the request, it sends an RMS-I message to RR
       (before commencing the burst or during the burst) that comprises
       fields that can be used to describe the burst that will be sent
       by RS (e.g., the bitrate and the size of the burst).

To be more consistent with the syntax (and hence more instructive), "the
bitrate and the size of the burst" should be changed to "the maximum
bitrate and the duration of the burst".

--- bvs --- will fix

   Section 6.2, step 2. 
       The burst duration may be calculated by RS, and its value may be
       updated by messages received from RR.

What messages from RR may be used to update the bust duration?

   Section 7. 
   o  Length:  A two-octet field that indicates the length of the Value
      field.

The unit is missing. In octets?

--- bvs --- will fix, bytes/octets is almost certainly the correct unit.

   Section 7.1.

The unit of Min RMS Buffer Fill Requirement and Max RMS Buffer Fill
Requirement is ms. Are the values measured in the media presentation
timeline? How does the RS utilize these values?

--- bvs -- The authors have gone back and forth on this issues a few
times. The intent is to have the RR describe its buffering requirements
to the RS. The RS does not know if the RR is a cell phone or a
super-computer, and typically does not know the capabilities (de-jitter,
decrypt, decode, application layer processing) and thus buffering
requirements of the client. Rather than encapsulate all of the
application-layer complexity in a transaction from RR to RS, we decided
to have the RR tell the RS the minimum and maximum amount of data it
considered useful. We had been assuming that the metric was "ms at the
nominal rate", but this requires more thought - particularly if we want
to cover VBR flows.

   Section 7.2.

What is the essential difference between Response equal to 0 and
Response equal to 2 (e.g. from implementation point of view)?

   Section 7.2.
      Extended RTP Seqnum of the First Burst Packet (32 bits):  The
      extended RTP sequence number of the first packet that will be sent
      as part of the rapid synchronization in the burst.  This allows RR
      to know if one or more packets have been dropped at the beginning
      of the burst. 32-bit extended RTP sequence number is constructed
      by putting the 16-bit RTP sequence number in the lower two bytes
      and octet 0's in the higher two bytes.

It should be clarified that "the 16-bit RTP sequence number" is not the
RTP sequence number of the packet in the burst stream.
Why does this field need to be 32 bits? You expect that there might be
more than 2^16-1 packets lost in the beginning of the burst.

--- bvs --- we have gone back and forth on "extended sequence numbers"
vs "sequence numbers" as well. In earlier versions of the draft, we
specified that if the extended portion of the sequence number was not
known it would be sent as zeros". In my opinion, the extended sequence
numbers are of limited value due to the bit rates of the streams
envisioned as well as the short duration of the acceleration bursts.
However, we stayed with extended sequence numbers in order to be
consistent the intent of the RTP design. There are some extreme cases
(uncompressed HD video with large RTT) in which extended sequence
numbers would be useful. The authors have not seen compelling arguments
for either case, so we welcome feedback on this point.

   Section 7.2.

How does RR utilize the Max Burst Bitrate conveyed in the RMS-I message?

--- bvs -- This is not specified in the document, as it is out of scope.
However, the client can use this value to assist it in managing buffer
levels.

   Section 7.2.
   The length of the feedback message MUST be set to 2+n, where n is the
   number of fields contained in the message.   

This is incorrect, as not all fields in RMS-I are of 32 bits.

---bvs will fix. This may also change if we go to TLV encoding

   Section 7.2.
      Extended RTP Seqnum of the First Multicast Packet (32 bits):  The
      extended RTP sequence number of the first packet received from the
      multicast session.

How to set the value of the higher two bytes of this field?

--- bvs -- need to clarify in document - often set to all zeros, but
sometimes set to the correct value as received in the SR.

[end]

BR, YK

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> Ali C. Begen (abegen)
> Sent: Monday, March 09, 2009 4:42 PM
> To: IETF AVT WG
> Subject: [AVT] New Version: 
> draft-versteeg-avt-rapid-synchronization-for-rtp-02
> 
> An updated version of our draft is available at:
> http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s
> ynchroniza
> tion-for-rtp-02.txt
> 
> As usual, comments are welcome.
> -acbegen
> 
> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:[email-masked]]
> 
> A new version of I-D,
> draft-versteeg-avt-rapid-synchronization-for-rtp-02.txt has been 
> successfuly submitted by Ali Begen and posted to the IETF repository.
> 
> Filename:	 draft-versteeg-avt-rapid-synchronization-for-rtp
> Revision:	 02
> Title:		 Unicast-Based Rapid Synchronization 
> with RTP Multicast
> Sessions
> Creation_date:	 2009-03-09
> WG ID:		 Independent Submission
> Number_of_pages: 32
> 
> Abstract:
> When a receiver joins a multicast session, it may need to acquire and 
> parse certain Reference Information before it can process any data 
> sent in the multicast session.  Depending on the join time, length of 
> the Reference Information repetition interval, size of the Reference 
> Information as well as the application and transport properties, the 
> time lag before a receiver can usefully consume the multicast data, 
> which we refer to as the synchronization delay, varies and may be 
> large.  This is an undesirable phenomenon for receivers that 
> frequently switch among different multicast sessions, such as video 
> broadcasts.  In this document, we describe a method using the existing

> RTP and RTCP protocol machinery that reduces the synchronization 
> delay.  In this method, an auxiliary unicast RTP session carrying the 
> Reference Information to the receiver precedes/ accompanies the 
> multicast flow.  This unicast flow may be transmitted at a faster than

> natural rate to further accelerate the synchronization.  The 
> motivating use case for this capability is multicast applications that

> carry real-time compressed audio and video.  However, the proposed 
> method can also be used in other types of multicast applications where

> the synchronization delay is long enough to be a problem.
>  
> 
> 
> 
> The IETF Secretariat.
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
> 

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: "Roni Even" <[email-masked]>
Date: Wed, 11 Mar 2009 18:53:42 +0200

Bill,

Since there is another draft on the same topic which will be presented, it will be helpful to agree on one draft as a starting point for a WG document, assuming you want one.

So it will be productive if the time will be suitable at least to the contributors of both drafts.

Regards

Roni

From: Bill Ver Steeg (versteb) [mailto:[email-masked]] 
Sent: Wednesday, March 11, 2009 6:29 PM
To: [email-masked]; [email-masked]; Ali C. Begen (abegen); [email-masked]
Cc: Dave Oran (oran)
Subject: Re: [AVT] NewVersion: draft-versteeg-avt-rapid-synchronization-for-rtp-02

Bvs

----- Original Message -----
From: Roni Even <[email-masked]>
To: Bill Ver Steeg (versteb); 'Ye-Kui Wang' <[email-masked]>; Ali C. Begen (abegen); 'IETF AVT WG' <[email-masked]>
Cc: Dave Oran (oran)
Sent: Wed Mar 11 12:10:54 2009
Subject: RE: [AVT]      NewVersion:     draft-versteeg-avt-rapid-synchronization-for-rtp-02

Bill,

-----Original Message-----

Ye-Kui Wang-

-----Original Message-----

Hi Ali, All,

[start]

   Section 1.

   Section 1.

   Section 5.

   Fig. 2.

   Fig. 3.

"RMR-R" -> "RMS-R"
"RMR-T"-> "RMS-T"

---bvs --- will fix

   Section 6.2, step 1.

---bvs --- will fix

   Section 6.2, step 2.

   Section 6.2, step 2.

--- bvs --- will fix

   Section 6.2, step 2.

   Section 7.

   Section 7.1.

   Section 7.2.

   Section 7.2.

   Section 7.2.

   Section 7.2.

   Section 7.2.

[end]

BR, YK

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Wed, 11 Mar 2009 14:00:57 -0400

Roni-
 
We are currently targeting a Tuesday 9-10:30 AM technical break out
session to discuss issues around the rapid synchronization of a receiver
to an RTP multicast stream. We may spill over a bit, but we want to
allow folks to be able to attend at least some of the behave session as
well.
 
Ye-Kui - Will you be attending the IETF sessions? If so, does this time
work for you?
 
By the way, we do need to come up with nomenclature that separates this
topic from the largely-unrelated topic of Colin's draft on RTP clock
synchronization. I find myself getting confused, so folks who are just
glancing at these threads and drafts would be well served by distinct
names. May I suggest "rapid acquisition of RTP multicast flows" as we
transition towards a WG item?

Bill VerSteeg

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roni Even
Sent: Wednesday, March 11, 2009 12:54 PM
To: Bill Ver Steeg (versteb); [email-masked]; Ali C. Begen
(abegen); [email-masked]
Cc: Dave Oran (oran)
Subject: Re: [AVT]NewVersion:
draft-versteeg-avt-rapid-synchronization-for-rtp-02

Bill,

Since there is another draft on the same topic which will be presented,
it will be helpful to agree on one draft as a starting point for a WG
document, assuming you want one.

So it will be productive if the time will be suitable at least to the
contributors of both drafts.

Regards

Roni

To: [email-masked]; [email-masked]; Ali C. Begen (abegen);

Yes, the intent is for an open technical session. We are coordinating
schedules of the existing contributors, and will have a suggested time.
It is looking like monday, maybe tuesday. We will let you know.

Bvs

----- Original Message -----
From: Roni Even <[email-masked]>
To: Bill Ver Steeg (versteb); 'Ye-Kui Wang' <[email-masked]>; Ali
C. Begen (abegen); 'IETF AVT WG' <[email-masked]>
Cc: Dave Oran (oran)
Sent: Wed Mar 11 12:10:54 2009
Subject: RE: [AVT]      NewVersion:
draft-versteeg-avt-rapid-synchronization-for-rtp-02

Bill,
I hope that this breakout session is open, in this case I would suggest
that
you will give people a couple of optional time slots to select.
Regards
Roni Even

-----Original Message-----
Bill

Ye-Kui Wang-

-----Original Message-----

Hi Ali, All,

[start]

   Section 1.

   Section 1.

   Section 5.

   Fig. 2.

   Fig. 3.

"RMR-R" -> "RMS-R"
"RMR-T"-> "RMS-T"

---bvs --- will fix

   Section 6.2, step 1.

---bvs --- will fix

   Section 6.2, step 2.

   Section 6.2, step 2.

--- bvs --- will fix

   Section 6.2, step 2.

   Section 7.

   Section 7.1.

   Section 7.2.

   Section 7.2.

   Section 7.2.

   Section 7.2.

   Section 7.2.

[end]

BR, YK

---

From: Ye-Kui Wang <[email-masked]>
Date: Wed, 11 Mar 2009 14:18:07 -0400

Bill,
 
Yes, I will be attending the AVT sessions. And the time you proposed works
for me. In addition, I would like to seek the possibility for people to dial
in for discussions. 
 
The term you proposed sounds good to me. 
 
BR, YK

  _____  

From: Bill Ver Steeg (versteb) [mailto:[email-masked]] 
Sent: Wednesday, March 11, 2009 2:01 PM
To: Roni Even; [email-masked]; Ali C. Begen (abegen); [email-masked]
Cc: Dave Oran (oran)
Subject: RE:
[AVT]NewVersion:draft-versteeg-avt-rapid-synchronization-for-rtp-02

Roni-
 
We are currently targeting a Tuesday 9-10:30 AM technical break out session
to discuss issues around the rapid synchronization of a receiver to an RTP
multicast stream. We may spill over a bit, but we want to allow folks to be
able to attend at least some of the behave session as well.

Ye-Kui - Will you be attending the IETF sessions? If so, does this time work
for you?
 
By the way, we do need to come up with nomenclature that separates this
topic from the largely-unrelated topic of Colin's draft on RTP clock
synchronization. I find myself getting confused, so folks who are just
glancing at these threads and drafts would be well served by distinct names.
May I suggest "rapid acquisition of RTP multicast flows" as we transition
towards a WG item?

Bill VerSteeg

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni
Even
Sent: Wednesday, March 11, 2009 12:54 PM
To: Bill Ver Steeg (versteb); [email-masked]; Ali C. Begen (abegen);
[email-masked]
Cc: Dave Oran (oran)
Subject: Re: [AVT]NewVersion:
draft-versteeg-avt-rapid-synchronization-for-rtp-02

Bill,

Since there is another draft on the same topic which will be presented, it
will be helpful to agree on one draft as a starting point for a WG document,
assuming you want one.

Regards

Roni

Yes, the intent is for an open technical session. We are coordinating
schedules of the existing contributors, and will have a suggested time. It
is looking like monday, maybe tuesday. We will let you know.

Bvs

----- Original Message -----
From: Roni Even <[email-masked]>
To: Bill Ver Steeg (versteb); 'Ye-Kui Wang' <[email-masked]>; Ali C.
Begen (abegen); 'IETF AVT WG' <[email-masked]>
Cc: Dave Oran (oran)
Sent: Wed Mar 11 12:10:54 2009
Subject: RE: [AVT]      NewVersion:
draft-versteeg-avt-rapid-synchronization-for-rtp-02

Bill,

-----Original Message-----

Ye-Kui Wang-

-----Original Message-----

Hi Ali, All,

[start]

   Section 1.

   Section 1.

   Section 5.

   Fig. 2.

   Fig. 3.

"RMR-R" -> "RMS-R"
"RMR-T"-> "RMS-T"

---bvs --- will fix

   Section 6.2, step 1.

---bvs --- will fix

   Section 6.2, step 2.

   Section 6.2, step 2.

--- bvs --- will fix

   Section 6.2, step 2.

   Section 7.

   Section 7.1.

   Section 7.2.

   Section 7.2.

   Section 7.2.

   Section 7.2.

   Section 7.2.

[end]

BR, YK

---

From: "Roni Even" <[email-masked]>
Date: Thu, 12 Mar 2009 18:16:40 +0200

Hi,

I will have a separate email with my review comments.

I have one comment on this thread

   Section 7.2.

Roni: I think that if you have a parameter in a message its semantics should be specified. If it is not then how would an RS know if to put a value in this parameter or just have it as unspecified.

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Thu, 12 Mar 2009 13:06:17 -0400

Roni-
 
The RS generates the RMS-I, and the semantics of the RMS-I are well
defined from the standpoint of the RS. The Max Burst BitRate is the
maximum rate at which the RS will send the burst. If the RS knows this
value, it should populate the field.
 
The document does not currently specify what the RR does with the Max
Burst Bitrate, because the RR could do a lot of different things with
it. It may manage the de-jitter buffer. It may manage a decode buffer.
It may manage a decrypt buffer. It may manage display buffer. It may
display progress bars. It may present different screens to the user
based on the anticipated duration of the stream acquisition process.
Most of this is payload/implementation specific, and we are trying to
stay away from specifying such behaviors.
 
So, in summary, we are trying to rigorously define the semantics of each
component of each packet that flows on the network as seen by the sender
of that message. We are currently not trying to define the
device-specific actions that a given device takes when receiving a
message. 
 
Having said that, it sounds like we should put some guidance in the text
regarding possible uses for the receiver. We do need to be careful not
to make to many assumptions about application-specific behaviors,
though.
 
bvs

From: Roni Even [mailto:[email-masked]] 
Sent: Thursday, March 12, 2009 12:17 PM
To: Bill Ver Steeg (versteb); [email-masked]; Ali C. Begen
(abegen); [email-masked]
Cc: Dave Oran (oran)
Subject: RE: [AVT] NewVersion:
draft-versteeg-avt-rapid-synchronization-for-rtp-02

Hi,

  
   Section 7.2.

Roni: I think that if you have a parameter in a message its semantics
should be specified. If it is not then how would an RS know if to put a
value in this parameter or just have it as unspecified.

---

From: "Roni Even" <[email-masked]>
Date: Wed, 18 Mar 2009 10:47:11 +0200

Hi,

In order to progress the work on the topic see
draft-versteeg-avt-rapid-synchronization-for-rtp-02 and
draft-peilin-avt-rtp-burst-01,

we will have the breakout session during the IETF 74 on Tuesday March 24th
at  9:00-10:30 AM   in Yosemite A  (I got us the room till 11:00)

We will not have a speaker phone but can probably use Skype out to call to a
conference bridge. (Can someone offer one?)

I will announce it also during the Monday session.

Regards

Roni Even

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 20 Mar 2009 10:13:30 -0700

Hi everyone,

Here is the bridge info - hoping that we will be able to dial from the meeting room. The details are below.

-acbegen

Date/Time:               MAR 24, 2009 at 9:00AM America/Los_Angeles
Length:                  120
Frequency:               1
Meeting ID:              170292365

Global Access Numbers:
http://cisco.com/en/US/about/doing_business/conferencing/index.html

    San Jose, CA: +1.408.525.6800  RTP:              +1.919.392.3330      
    US/Canada:  +1.866.432.9903    United Kingdom:   +44.20.8824.0117
    India:      +91.80.4350.1111   Germany:          +49.619.6773.9002
    Japan:      +81.3.5763.9394    China:            +86.10.8515.5666

TO ATTEND A VOICE ONLY CONFERENCE
1. Dial into Cisco Unified MeetingPlace (view the Access Numbers and link above)
2. Press 1 to attend the meeting
3. Follow the prompts to enter the Meeting ID 170292365 and join the meeting

SUPPORT
Information about this Conference: Contact Ali Begen, 14085257308
Cisco IT Support Center: Attend the Voice Conference and then press #0 on your phone keypad

> Sent: Wednesday, March 18, 2009 1:47 AM
> To: [email-masked]; 'Tom Taylor'
> Cc: Dave Oran (oran); 'Peilin YANG'; 'Zou ZiXuan'; Bill Ver 
> Steeg (versteb); [email-masked]; Ali C. Begen (abegen)
> Subject: breakout session on rapid acquisition for multicast 
> rtp sessions
> 
> Hi,
> 
>  
> 
> we will have the breakout session during the IETF 74 on 
> Tuesday March 24th  at  9:00-10:30 AM   in Yosemite A  (I got 
> us the room till 11:00)
> 
> We will not have a speaker phone but can probably use Skype 
> out to call to a conference bridge. (Can someone offer one?)
>

---

From: "Roni Even" <[email-masked]>
Date: Fri, 20 Mar 2009 19:34:20 +0200

Ali,
Thanks, can you connect also with IP phone since Cullen suggested that he
can bring one.
If not I can use my skype out to call
Roni

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: Friday, March 20, 2009 7:14 PM
To: Roni Even; [email-masked]; Tom Taylor
Cc: Dave Oran (oran); Peilin YANG; Zou ZiXuan; Bill Ver Steeg (versteb);
[email-masked]
Subject: RE: breakout session on rapid acquisition for multicast rtp
sessions

Hi everyone,

Here is the bridge info - hoping that we will be able to dial from the
meeting room. The details are below.

-acbegen

Global Access Numbers:

TO ATTEND A VOICE ONLY CONFERENCE
1. Dial into Cisco Unified MeetingPlace (view the Access Numbers and link
above)
2. Press 1 to attend the meeting
3. Follow the prompts to enter the Meeting ID 170292365 and join the meeting

SUPPORT
Information about this Conference: Contact Ali Begen, 14085257308
Cisco IT Support Center: Attend the Voice Conference and then press #0 on
your phone keypad

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 20 Mar 2009 10:40:20 -0700

Sure, we just need a computer with a good set of mic/speakers.

-acbegen

> Sent: Friday, March 20, 2009 10:34 AM
> To: Ali C. Begen (abegen); [email-masked]; 'Tom Taylor'
> Steeg (versteb); [email-masked]; Cullen Jennings (fluffy)
> Subject: RE: breakout session on rapid acquisition for 
> multicast rtp sessions
> 
> Ali,

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 20 Mar 2009 18:24:19 -0400

On Wed, Mar 18, 2009 at 4:47 AM, Roni Even <[email-masked]> wrote:

> We will not have a speaker phone but can probably use Skype out to call to
> a conference bridge. (Can someone offer one?)
>

Do you want a speakerphone and / or a bridge ? The Secretariat tells me this
could be done.

Marshall

---

From: "Roni Even" <[email-masked]>
Date: Sat, 21 Mar 2009 02:15:44 +0200

Marshall,

We have a bridge but no speaker phone, so it will be good if you can help
with one.

Regards

Roni

From: Marshall Eubanks [mailto:[email-masked]] 
Sent: Saturday, March 21, 2009 12:24 AM
To: Roni Even
Cc: [email-masked]; Tom Taylor; Bill Ver Steeg (versteb); Dave Oran (oran)
Subject: Re: [AVT] breakout session on rapid acquisition for multicast rtp
sessions

Hi,

Marshall

Regards

Roni Even

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Tue, 24 Mar 2009 12:07:36 -0400

We are planning to discuss the following in the breakout today. The
first 5 items are not contentious, and we should be able to cover them
quickly and assign an owner.
 
If there are other items we need to address, please let me know.
 
1- Name of the draft
2- TLV encapsulation vs fixed fields with defaults
3- FT co-location with RS
4- add details on the usage of additional fields
5- formalize extension fields
6- SDP descriptions of RTP/RTCP flows and interactions with RTCPMUX
7- rate adaptive flows
8- multiple streams from a given RS to a given RR
9- assumptions regarding network topology 
 
Bill VerSteeg