Subject: [siprec] comments on draft-ietf-siprec-req-04

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 9 Nov 2010 20:39:20 -0800

I read the draft today in preparation for the working group meeting.
Prior to that, I had not been following the work of this group very
closely, so please excuse these comments if they have already been
discussed.

1) with video, you have to have received an I-frame otherwise the
subsequent frames are not usable. In a live session, you can request a
new I-frame when necessary. For a recorded video stream, how do you plan
to handle this in general and for searching? I think requirement(s)
should be added to address this.

2) in a multipoint conference, each participant sees something different
and a subset of the total conference. How do you make sure you have the
whole conference as well as what each participant experienced? I think
it would be good to add some requirements in this area as well.

Cheers,
Charles

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Nov 2010 17:48:28 +0800

> closely, so please excuse these comments if they have already been

Welcome to the party Charles. Hope you will stay and contribute.

> should be added to address this.

I don't know if this is really something for the requirements, or if it 
is just a competitive area for implementations. I suspect the latter.

Ideally, when the SRC starts recording video it will either start when 
it gets an I-frame, or will explicitly request an I-frame at that time. 
But the SRC can be constructed in a variety of ways depending on its 
relationship to the CS participants, and it may not have that much 
control. At the end of the day you must do with what you can get.

(Note that I know nearly nothing about video encoding, so I will defer 
to anyone who has better insight into this.)

In any case, if you would like to see something different in the 
requirements doc, please send text.

> it would be good to add some requirements in this area as well.

There are some place holders about conferencing that need more fleshing 
out. Please feel free to send text.

There is a real difference between "recording a conference" and 
recording a CS where one of the participants happens to be in a conference.

To properly record a conference, the best way is for the conference 
focus to be the SRC. It then has access to everything, so that it 
becomes just a matter of conveying that to the SRS. I think we have 
described enough in the metamodel to represent much of this, but perhaps 
not everything.

For the other case I have an example in mind: Alice calls the support 
center with a question about a problem with her computer. In the midst 
of this, she decides she needs to conference in Bob so he can also 
provide info to the support person. Alice might be the focus, or the 
focus might be some server in her SP's network. Depending on the 
signaling, the support center and its SRC may not know there is a 
conference, or may know they are talking to a focus and be able to ask 
for a roster and so discover Bob is present. Either way, the SRC is 
probably just receiving a single mixed audio stream containing Alice+Bob.

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 10 Nov 2010 02:37:38 -0800

Hi Paul,

Thanks for the warm welcome. Please see comments inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat (pkyzivat)
> Sent: Wednesday, November 10, 2010 5:48 PM
> To: [email-masked]
> Subject: Re: [siprec] comments on draft-ietf-siprec-req-04
> 
> 
> 

Fair enough. How about this:

The mechanism MUST provide the SRS with the complete set of out-of-band
parameters about a media stream required to be able to play back the
media. This set must be extensible as it will vary depending on the type
of media, the codec, etc. For example, this would include the media
level attributes that were ultimately agreed upon for the media stream.

> described enough in the metamodel to represent much of this, but
perhaps

I'll take a shot at that as well:

The mechanism MUST provide the SRS with a way to let a conference focus
know that it is not just another participant but rather a special entity
that needs to receive all media streams associated with the conference
rather than just the subset the focus might otherwise choose to make
available to a typical participant.

Cheers,
Charles

> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Nov 2010 19:15:58 +0800

inline

> level attributes that were ultimately agreed upon for the media stream.

Assuming (as we generally are) that there will be an O/A exchange 
between the SRC and SRS to set up the media streams conveyed to the SRS, 
is there anything that you are looking for that would not naturally be 
conveyed via that O/A exchange?

> available to a typical participant.

For the moment, we have restricted the scope to cases where the SRC 
initiates the RS with the SRS. So if the SRC is a focus and is 
establishing the RS it should know all that stuff. Unless of course 
somebody just refers the conf focus to an SRS and it only discovers that 
after the fact. In that case it would be an "SRC-capable" focus that 
only discovers it should be an SRC after the fact. I guess that is 
possible. There has already been a proposal of a mechanism for that fact 
to be discovered. I hadn't seen the need for it, but maybe this is it.

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 10 Nov 2010 03:36:55 -0800

More inline

> From: Paul Kyzivat (pkyzivat)
> Sent: Wednesday, November 10, 2010 7:16 PM
> To: Charles Eckel (eckelcu)
> Cc: [email-masked]

Nope, that would be sufficient. Some of the discussion in the meeting
today in regard to the metadata draft made me think that simply the
media type and codec were being stored per media stream by the SRS. I
wanted to make sure additional attributes were made available to and
stored by the SRS.

> to be discovered. I hadn't seen the need for it, but maybe this is it.

That should cover it.

Cheers,
Charles

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 10 Nov 2010 18:11:26 +0530

Hi Charles,

Please see inline 

> Behalf Of Charles Eckel (eckelcu)
> Sent: Wednesday, November 10, 2010 7:37 PM
> To: Paul Kyzivat (pkyzivat)
> Cc: [email-masked]
> > > media. This set must be extensible as it will vary depending on
the
> type

In implementations, the Media Stream Reference attribute provided in
Media Stream block will have reference to the information conveyed in
O/A between SRC and SRS. Please let us know in case you see a need to
have any other attributes in Media Stream.

Thanks,
Ram

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 11 Nov 2010 15:49:03 +0100

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
> Sent: 10 November 2010 11:37
> > > media. This set must be extensible as it will vary 
> depending on the
> type
[JRE] I am not sure it is necessarily clear from this thread that the O/A exchange on the CS is separate from the O/A exchange on the RS (between the SRC and the SRS). So parameters could be quite different, e.g., one video codec on the CS but a different video codec on the RS. This assumes the SRC takes decoded video, encodes it again, and sends it to the SRS (let's call this approach A). Alternatively, the SRC could negotiate the same codec on the RS as is used on the CS, and therefore the SRC can take encoded video frames received from the CS and transmit them directly on the RS (approach B). The same principles apply to audio.

With approach A, the O/A exchange with the SRS will tell the SRS the codec used on the RS, but not the codec used on the CS, and similarly for any other parameters concerned with the coding of the video stream. There has been some discussion whether, as part of metadata, the SRS needs to know the original codec (used on the CS).

By the way, an SRC that implements approach A could still use approach B in cases where it happens to negotiate use of the same codec and parameters.

The advantage of approach A is that there can be flexibility in the choice of codecs, e.g., a different codec could be used on the RS if the one used on the CS is not available at the SRS, or if the SRC wants to use a codec with lower bandwidth for the RS. Approach A also allows the SRC to mix streams from the two directions in the case of audio, thereby saving bandwidth on the RS at the expense of not being able to playback the two streams separately. The advantage of approach B is much lower processing overhead and lower delay at the SRC. Considerations for video might be different from those for audio, e.g., the processing overhead of approach A might be a lot more significant for video than for audio, whereas the potential bandwidth savings of approach A might be greater for video than for audio.

John (as individual)

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 11 Nov 2010 17:15:57 -0800

Great point John. I was assuming A but that would be good to clarify.
I think it is important to support approach A. You can essentially
simulate approach B with approach A for the sake efficiency or for other
reasons, but not vice versa.

Cheers,
Charles

> From: Elwell, John [mailto:[email-masked]]
> Sent: Thursday, November 11, 2010 10:49 PM
> To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat)
> Cc: [email-masked]
> Subject: RE: [siprec] comments on draft-ietf-siprec-req-04
> 
> 
> 
> > > between the SRC and SRS to set up the media streams conveyed to
the
> > SRS,
> [JRE] I am not sure it is necessarily clear from this thread that the
O/A exchange on the CS is
> separate from the O/A exchange on the RS (between the SRC and the
SRS). So parameters could be quite
> different, e.g., one video codec on the CS but a different video codec
on the RS. This assumes the SRC
> takes decoded video, encodes it again, and sends it to the SRS (let's
call this approach A).
> Alternatively, the SRC could negotiate the same codec on the RS as is
used on the CS, and therefore
> the SRC can take encoded video frames received from the CS and
transmit them directly on the RS
> (approach B). The same principles apply to audio.
> 
> With approach A, the O/A exchange with the SRS will tell the SRS the
codec used on the RS, but not the
> codec used on the CS, and similarly for any other parameters concerned
with the coding of the video
> stream. There has been some discussion whether, as part of metadata,
the SRS needs to know the
> original codec (used on the CS).
> 
> By the way, an SRC that implements approach A could still use approach
B in cases where it happens to
> negotiate use of the same codec and parameters.
> 
> The advantage of approach A is that there can be flexibility in the
choice of codecs, e.g., a
> different codec could be used on the RS if the one used on the CS is
not available at the SRS, or if
> the SRC wants to use a codec with lower bandwidth for the RS. Approach
A also allows the SRC to mix
> streams from the two directions in the case of audio, thereby saving
bandwidth on the RS at the
> expense of not being able to playback the two streams separately. The
advantage of approach B is much
> lower processing overhead and lower delay at the SRC. Considerations
for video might be different from
> those for audio, e.g., the processing overhead of approach A might be
a lot more significant for video
> than for audio, whereas the potential bandwidth savings of approach A
might be greater for video than
> for audio.
> > > >> described enough in the metamodel to represent much of this,
but
> > > > The mechanism MUST provide the SRS with a way to let a
conference
> > focus
> > > > know that it is not just another participant but rather a
special
> > entity
> > > somebody just refers the conf focus to an SRS and it only
discovers
> > that
> > > possible. There has already been a proposal of a mechanism for
that
> > fact