Subject: [siprec] Do we need a stream element?

From: "Elwell, John" <[email-masked]>
Date: Fri, 5 Aug 2011 11:03:51 +0200

(as individual)

Do we need a stream element in the XML? In Quebec we said start and stop times should be tied to the association between participant and stream, not to the stream itself. This seems to suggest they be part of the send and recv sub-elements of a participant element. The mode element also seems not to be needed, since mixed or separate can be deduced from other information. The only relevant information seems to be the label.

So it seems to be a waste of space for send and recv sub-elements of a participant element to contain a unique ID pointing to a stream element that then just contains a label. Why don't the send and recv elements simply contain the label (plus start and stop times, to meet what was decided in Quebec)?

In other words, the MediaStream element in the model is entirely represented by a media description in SDP.

For example, the schema might look something like this:

<xs:element name="send" type="sendRecvType"
  minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="recv" type="sendRecvType"
  minOccurs="0" maxOccurs="unbounded"/>

<xs:complexType name="sendRecvType">
  <xs:sequence>
    <xs:element name="label" type="xs:string"
      minOccurs="0" maxOccurs="1"/>
    <xs:element name="start-time" type="xs:dateTime"
      minOccurs="0"/>
    <xs:element name="stop-time" type="xs:dateTime"
      minOccurs="0"/>
    <xs:element name="extensiondata" type="extensiondata"
      minOccurs="0"/>
  </xs:sequence>
</xs:complexType>

John

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Aug 2011 10:20:25 -0400

John,

> In other words, the MediaStream element in the model is entirely represented by a media description in SDP.

I think your point here is that the stream "class" will still exist in 
the model, but its conveyed entirely in SDP and thus does not need an 
xml representation.

One thing the xml element provides is a way to assign a true globally 
unique id, which allows the same stream to be referenced from multiple 
recording sessions. Until now, we have not stated that labels are unique 
ids. Rather, we have said (at least informally) that the labels are 
transient, used to bind the stream xml to the SDP within a single message.

I suppose we *could* specify a UUID representation that can be used as a 
label in SDP. (That is possible, but would have to be an unusual radix64 
representation, or we could use hex.)

I'm a bit reluctant to go this way because it eliminates the opportunity 
to associate other data with a stream, including extension data. But 
lets discuss it further.

	Thanks,
	Paul

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

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 8 Aug 2011 10:08:07 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 05 August 2011 15:20
> To: [email-masked]
> Subject: Re: [siprec] Do we need a stream element?
> 
> John,
> 
> > Do we need a stream element in the XML? In Quebec we said 
> start and stop times should be tied to the association 
> between participant and stream, not to the stream itself. 
> This seems to suggest they be part of the send and recv 
> sub-elements of a participant element. The mode element also 
> seems not to be needed, since mixed or separate can be 
> deduced from other information. The only relevant information 
> seems to be the label.
> >
> > So it seems to be a waste of space for send and recv 
> sub-elements of a participant element to contain a unique ID 
> pointing to a stream element that then just contains a label. 
> Why don't the send and recv elements simply contain the label 
> (plus start and stop times, to meet what was decided in Quebec)?
> >
> > In other words, the MediaStream element in the model is 
> entirely represented by a media description in SDP.
> 
[JRE] From past discussions, I am led to believe that a stream element represents an RS stream, and therefore the idea of having a unique ID that works from different RSs doesn't seem relevant.

> to associate other data with a stream, including extension data. But 
[JRE] I see your point, but would such extension data be more appropriate as part of a send or recv element?

John (as individual)

John Elwell
Tel: +44 1908 817801 (office and mobile)
Email: [email-masked]
http://www.siemens-enterprise.com/uk/

Siemens Enterprise Communications Limited.
Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.
Registered No: 5903714, England.

Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 08 Aug 2011 14:34:23 -0400

> [JRE] From past discussions, I am led to believe that a stream element represents an RS stream, and therefore the idea of having a unique ID that works from different RSs doesn't seem relevant.

I suspect maybe we are still not all on the same page about this.

Lets consider the case of a UA that is its own SRC. I pick that case 
simply because it is then plausible that it knows a fair amount about 
the things it is recording.

For instance, it might be an office phone, P, in an office that gets a 
lot of calls and wants to record them all. It could establish an RS at 
the beginning of the day, and use it for all calls in which it is involved.

Assume P makes a voice call to A. Then after that completes, P gets a 
call from B, and that completes.

If P does its own mixing, then it needs only a single m-line in the RS 
to accomplish this, using if first for the call with A and then for the 
call with B.

The question is whether that is one MS object, or two.

There will be two session elements, one for each call. Each will refer 
to one MS element - either the same one, or a different one. If its a 
single one, then for the duration of the first call the participants of 
the MS will be P and A, while during the 2nd call the participants will 
be P & B. Is that enough for the SRS to understand what is going on?

It gets more complex of the two calls are overlapped in time. Perhaps 
the call from B comes before the call with A is over. So P puts A on 
hold, answers and completes the call with B and then resumes the call 
with A.

In that case, if there is no MoH, P may still need only a single m-line 
in the RS to handle this. Then, the participants for the only MS are 
first P&A, then P&B, then P&A. The MS would then need to be switched 
from the first session, to the second, and back to the first.

I think this *can* work either way, and is to some extent a matter of 
taste. But it has to be carefully documented one way or the other. In 
*my* mind having separate MS objects makes sense, but maybe that is just 
a bias on my part.

	Thanks,
	Paul

> [JRE] I see your point, but would such extension data be more appropriate as part of a send or recv element?

I think either place could make sense, but for different things.
If you have data about why the sending is taking place or what it is 
about, then that belongs on the <send> element. If you have data on why 
the stream as a whole exists, regardless of sender, then extending the 
MS makes more sense. (But if the MS merely represents the m-line in the 
RS, then metadata on it probably doesn't make much sense.)

	Thanks
	Paul

---

From: Leon Portman <[email-masked]>
Date: Wed, 10 Aug 2011 16:57:58 +0300

I also think it will be cleaner to have dedicated MS element. We can think about scenarios where it can be "reused" by different participants.

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Monday, August 08, 2011 9:34 PM
To: Elwell, John
Cc: [email-masked]
Subject: Re: [siprec] Do we need a stream element?

On 8/8/11 4:08 AM, Elwell, John wrote:
>> start and stop times should be tied to the association between 
>> participant and stream, not to the stream itself.
>> This seems to suggest they be part of the send and recv sub-elements 
>> of a participant element. The mode element also seems not to be 
>> needed, since mixed or separate can be deduced from other 
>> information. The only relevant information seems to be the label.
>>>
>> sub-elements of a participant element to contain a unique ID pointing 
>> to a stream element that then just contains a label.
>> Why don't the send and recv elements simply contain the label (plus 
>> start and stop times, to meet what was decided in Quebec)?
>>>
>> I think your point here is that the stream "class" will still exist 
>> in the model, but its conveyed entirely in SDP and thus does not need 
>> an xml representation.
>>
>> unique id, which allows the same stream to be referenced from 
>> multiple recording sessions. Until now, we have not stated that 
>> labels are unique ids. Rather, we have said (at least informally) 
>> that the labels are transient, used to bind the stream xml to the SDP 
>> within a single message.

	Thanks,
	Paul

	Thanks
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 11 Aug 2011 08:44:18 -0700

The media stream element was more intuitive to me when I understood it
to describe the CS media streams. Now that I understand it to be the RS
media streams, I agree with John that the SDP could be sufficient.
I believe I understand the points Paul and Leon are making with respect
to long duration recordings; however, it does seem to me that we now
have multiple mechanisms to describe very similar information (RS SDP,
RS media stream, send/recv elements). I would prefer to eliminate some
of the redundancy, otherwise I fear we will create duplications, and
even worse, inconsistencies. 

Cheers,
Charles

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Leon Portman
> Sent: Wednesday, August 10, 2011 6:58 AM
> To: Paul Kyzivat; Elwell, John
> Cc: [email-masked]
> I also think it will be cleaner to have dedicated MS element. We can
think about scenarios where it
> can be "reused" by different participants.
> 
> Leon
> 
sub-elements
> >> sub-elements of a participant element to contain a unique ID
pointing
> > [JRE] From past discussions, I am led to believe that a stream
element represents an RS stream, and
> therefore the idea of having a unique ID that works from different RSs
doesn't seem relevant.
> > [JRE] I see your point, but would such extension data be more
appropriate as part of a send or recv
> element?

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 18 Aug 2011 12:34:42 +0200

> From: Charles Eckel (eckelcu) [mailto:[email-masked]] 
> Sent: 11 August 2011 16:44
> To: Leon Portman; Paul Kyzivat; Elwell, John
> Cc: [email-masked]
> Subject: RE: [siprec] Do we need a stream element?
> 
[JRE] Yes, that was basically my concern - redundant information and/or too many ways to accomplish the same thing.

John (as individual)

> Behalf Of Paul Kyzivat
> > > Siemens Enterprise Communications Limited is a Trademark 
> Licensee of
> Siemens AG.
> > >
> > >
> > >>
> > >> 	Thanks,
> > >> 	Paul
> > >>

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Fri, 19 Aug 2011 23:12:27 +0530

I remember that we have discussed during one of the interim before
IETF-81 for the need of (Media) stream global-id which is different from
label attribute in SDP. In case of RS to CS for 1:1 mapping, stream
element and its global id looks overhead which I agree with John. 

I could recollect two of the scenario wherein stream element is useful:

Scenario 1: CS:RS is in 1:N with multiple m-lines and unmixed stream to
SRS.  Here there is a need to map single stream with different RS SDP
consistently using a unique id wherein stream global id shall be used.
Few examples are 
	A ) Typical call center scenario wherein single customer call is
transferred to multiple agents in the single session.
   	B)  Start/Stop of CS which results in multiple RS.

Scenario 2: Multicast scenario (Ram mentioned in another mail thread)

In case better way to solve the above scenario, Please let us discuss
about it.

Thanks
Partha

> Behalf Of Elwell, John
> Sent: Thursday, August 18, 2011 4:05 PM
> To: Charles Eckel (eckelcu); Leon Portman; Paul Kyzivat
> Cc: [email-masked]
> [JRE] Yes, that was basically my concern - redundant information
and/or
> too many ways to accomplish the same thing.
> 
> John (as individual)
> 
> 
> >
> > Cheers,
> > Charles
> >
> > > >> in the model, but its conveyed entirely in SDP and thus does
not
> > need
> > > >> that the labels are transient, used to bind the stream xml to
> the
> > SDP
> > > >> within a single message.
> > > to accomplish this, using if first for the call with A and then
for
> > the
> > > single one, then for the duration of the first call the
> participants
> > of
> > > *my* mind having separate MS objects makes sense, but maybe that
is
> > just
> > > >> to associate other data with a stream, including extension
data.
> > But
> > > about, then that belongs on the <send> element. If you have data
on
> > why
> > > MS makes more sense. (But if the MS merely represents the m-line
in
> > the

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 22 Aug 2011 09:08:36 +0200

Partha, 

Of course, we agreed an MS would have a unique identifier (June interim meeting), but what has emerged since then is that the unique identifier seems to be the only attribute needed for MS, which led me to doubt the need for the element in XML - just reference the SDP media description from participant send/recv elements. Having an explicit MS element with unique identifier seems to be a significant overhead for simple usages just to accommodate these more complex usages. I don't particularly want to re-open the old issue, but it concerns me that we don't have a clear definition of a MediaStream object. I can't find one in draft-03, It seems it represents neither a CS media stream (because some people insisted that a media stream can, under some circumstances, have a lifetime outside a single CS), nor an RS media stream (because of the arguments you make below). So what is it exactly? Please can somebody propose a clear and concise definition of a MediaStream object?

John (as individual)

> From: Ravindran Parthasarathi [mailto:[email-masked]] 
> Sent: 19 August 2011 18:42
> To: Elwell, John; Charles Eckel (eckelcu); Leon Portman; Paul Kyzivat
> Cc: [email-masked]
> > > The media stream element was more intuitive to me when I 
> understood
> > it
> [mailto:[email-masked]] On
> > > Behalf Of Leon Portman
> > > > the beginning of the day, and use it for all calls in 
> which it is
> > > involved.
> > > >
> > > > the MS will be P and A, while during the 2nd call the 
> participants
> > > will
> > > > the call from B comes before the call with A is over. 
> So P puts A
> > on
> > > > If you have data about why the sending is taking place 
> or what it
> > is
> > > > > Registered office: Brickhill Street, Willen Lake, 
> Milton Keynes,
> > > MK15 0DJ.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Aug 2011 09:50:48 -0400

John,

I went looking for a definition of media stream to borrow, and find that 
its not as easy to find as I thought it would be. For instance I didn't 
find it directly in RFC 4566 (SDP).

SDP defines (multimedia) *session*. Within that it has "media 
description", which starts to get there. But it only deals with the 
mechanics, not the semantics, of the media stream. And its the semantics 
that we care about here. And RFC 3550 (RTP) suffers similarly.

SDP defines session as:

    Session: A multimedia session is a set of multimedia senders and
       receivers and the data streams flowing from senders to receivers.
       A multimedia conference is an example of a multimedia session.

 From this we might extrapolate a definition for a Media Stream as:

    Media Stream: A media stream is a set of multimedia senders and
       receivers and a data stream flowing from senders to receivers.

For siprec, we would narrow this:

    Media Stream: A media stream is a set of multimedia senders and
       receivers engaged in a communication session, and a data stream
       flowing from senders to receivers.

This may still not be quite what it should be. I'm having difficulty 
capturing how multiple communication sessions fit into this. In the 
above my thought is that the senders and receivers must be in a CS, but 
they don't all have to be in the same one, or only one.

	Thanks,
	Paul

On 8/22/11 3:08 AM, Elwell, John wrote:
>>>>> be P&  B. Is that enough for the SRS to understand what is going
>>> on?
>>>>>
>>>>> about, then that belongs on the<send>  element. If you have data
>> on
>>>> why

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Mon, 22 Aug 2011 19:26:16 +0530

Paul,

Please read inline.

Thanks
Partha

>From: Paul Kyzivat [mailto:[email-masked]]
>Sent: Monday, August 22, 2011 7:21 PM
>To: Elwell, John
>Cc: Ravindran Parthasarathi; Charles Eckel (eckelcu); Leon Portman;
>[email-masked]
[Partha] How about including communication session group instead of
communication session. So, the updated definition is 

    Media Stream: A media stream is a set of multimedia senders and
      receivers engaged in a communication session group, and a data
stream
      flowing from senders to receivers.

>> Of course, we agreed an MS would have a unique identifier (June
>interim meeting), but what has emerged since then is that the unique
>identifier seems to be the only attribute needed for MS, which led me
to
>doubt the need for the element in XML - just reference the SDP media
>description from participant send/recv elements. Having an explicit MS
>element with unique identifier seems to be a significant overhead for
>simple usages just to accommodate these more complex usages. I don't
>particularly want to re-open the old issue, but it concerns me that we
>don't have a clear definition of a MediaStream object. I can't find one
>in draft-03, It seems it represents neither a CS media stream (because
>some people insisted that a media stream can, under some circumstances,
>have a lifetime outside a single CS), nor an RS media stream (because
of
>the arguments you make below). So what is it exactly? Please can
>somebody propose a clear and concise definition of a MediaStream
object?

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Aug 2011 10:32:54 -0400

>        flowing from senders to receivers.

I don't think this is right, for a variety of reasons:

- it seems to suggest that you can't be a sender or receiver to an MS
   unless you are in a CSG. That isn't consistent with how we have
   things.

- I presume by this change that you are suggesting that those cases
   where a MS is in more than one CS are also cases where those CSs are
   in a group. But I don't think that is always the case. I'm thinking
   of a multicast MS used for MoH, that may be shared by all CSs that
   are using it for their MoH media.

But I think this does expose some added trouble with my definition as 
well. Specifically, we separate the MS from the senders/receivers of 
that media stream, considering it to be the same stream even as the 
senders and receivers change over time.

(I was going to refer to George Washington's axe here, but see 
http://en.wikipedia.org/wiki/Ship_of_Theseus for a more culturally 
neutral treatment of the same point.)

So, to take another crack at it:

    Media Stream: A data stream flowing between an evolving set of
       senders and receivers engaged with one another in one or more
       communication sessions.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 22 Aug 2011 17:03:28 +0200

Paul, 

> Sent: 22 August 2011 15:33
> To: Ravindran Parthasarathi
> Cc: Elwell, John; Charles Eckel (eckelcu); Leon Portman; 
> [email-masked]
[JRE] Thanks for attempting to find a definition. I think this about captures where we are, but in my opinion it is still rather vague - from this definition it isn't coupled to an RS, and although coupled to one or more CSs, is not constrained to a single CS. So, as an SRC, what criteria would I use to decide whether data streams from two CSs are really a single Media Stream object or two Media Stream objects?

In the object-orientated world, one usually tries to define an object class to represent a tangible set of objects in some way - if you can't define what these objects are, this might be good grounds for questioning your choice of object class. For me, it is the same here. I am uncomfortable with this class, simply because we are having difficulty deciding when something is a single object of this class and when it is several.

John (as individual)

John Elwell

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Aug 2011 11:31:17 -0400

John,

I share your discomfort - I don't think the definition is right yet.
But I do think there is a concept there needing a definition.

Some *examples* of this:

- my "side" of the audio part of a conversation with you,
   contained within a CS between you and me.

- my "side" of the audio part of a conversation with a call center
   agent, contained within a CS between me and him, but also going
   to the call center supervisor who is listening in.

- a mix of the audio part of a conversation between me and you,
   from my perspective, including the audio I sent to you and the
   audio I received from you.

- a MoH audio stream generated and sent by your phone when you put
   me on hold.

- a MoH audio stream sent by an MoH server to whom I have been
   transferred while on hold. A unique stream generated for me.

- a MoH multicast audio stream that was offered to me by you
   when you put me on hold. That same stream has been shared by all
   those put on hold by the PBX you use.

- a mixed audio stream for a conference. It contains a mix of the
   loudest two participants at any one time.

In each case, the media stream exists over a period of time.
The contents of the stream can be forwarded to the SRS using one of the 
RTP streams in an RS. And portions of that MS might be forwarded using 
different RTP streams and/or RSs.

Without yet nailing down the definition, do you agree that there is a 
well defined concept (class) here?

	Thanks,
	Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 23 Aug 2011 14:56:50 +0530

John,

Please see inline

> Sent: Monday, August 22, 2011 9:01 PM
> To: Elwell, John
> Cc: [email-masked]
> > [JRE] Thanks for attempting to find a definition. I think this about
> captures where we are, but in my opinion it is still rather vague -
> from this definition it isn't coupled to an RS, and although coupled
to
> one or more CSs, is not constrained to a single CS. So, as an SRC,
what
> criteria would I use to decide whether data streams from two CSs are
> really a single Media Stream object or two Media Stream objects?
> >
> > In the object-orientated world, one usually tries to define an
object
> class to represent a tangible set of objects in some way - if you
can't
> define what these objects are, this might be good grounds for
> questioning your choice of object class. For me, it is the same here.
I
> am uncomfortable with this class, simply because we are having
> difficulty deciding when something is a single object of this class
and
> when it is several.

While we work on refining the definition, I still feel it is better to
have stream element in XML. I understand your point that after the
discussions in IETF81 we see that most of the attributes of stream are
attributes of associations and so the stream element will have only the
unique ID (UUID or radix64) and the label attribute and hence it may
seem a overhead. IMO it is still better to have as it provides a lot of
flexibility(e.g. some of the use-cases that Paul, Partha, me pointed)
and will be useful for future extensions. And I don't see any
duplication of information like Charles mentioned.  The XML is not going
to duplicate anything which is already possible to represent in SDP

Regards,
Ram

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 23 Aug 2011 12:44:00 +0200

> Sent: 22 August 2011 16:31
> To: Elwell, John
> Cc: Ravindran Parthasarathi; Charles Eckel (eckelcu); Leon 
> Portman; [email-masked]
> > [JRE] Thanks for attempting to find a definition. I think 
> this about captures where we are, but in my opinion it is 
> still rather vague - from this definition it isn't coupled to 
> an RS, and although coupled to one or more CSs, is not 
> constrained to a single CS. So, as an SRC, what criteria 
> would I use to decide whether data streams from two CSs are 
> > In the object-orientated world, one usually tries to define 
> an object class to represent a tangible set of objects in 
> some way - if you can't define what these objects are, this 
> might be good grounds for questioning your choice of object 
> class. For me, it is the same here. I am uncomfortable with 
> this class, simply because we are having difficulty deciding 
> when something is a single object of this class and when it 
> is several.
> >
> > John (as individual)
> 
> John,
> 
[JRE] Yes, each of the examples you give can be an MS. And I guess it is possible you could terminate an RS and start a new RS to resume recording of the same MS, so there might not be a 1:1 relationship between MS and RS. None of these examples show why a MS can have a lifetime outside a CS - they all sound to me like they are implicitly within the context of a CS. So it doesn't answer my question about when a stream in the context of one CS is considered to be the same as a stream in the context of another CS, and hence the same MS object.

Or putting it another way, if there is no CS in existence at a given point in time, I would assume there is no MS in existence. So when the last CSs terminates, do its associated MSs die, or can they exist in a sort of hibernation and be revived when the next CS starts? Or in this situation, does the new CS have to have new MSs?

John (as individual)

John Elwell

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Aug 2011 10:21:19 -0400

On 8/23/11 6:44 AM, Elwell, John wrote:
[snip]
> [JRE] Yes, each of the examples you give can be an MS. And I guess it is possible you could terminate an RS and start a new RS to resume recording of the same MS, so there might not be a 1:1 relationship between MS and RS.

Yes, that is my thinking.

> None of these examples show why a MS can have a lifetime outside a CS - they all sound to me like they are implicitly within the context of a CS. So it doesn't answer my question about when a stream in the context of one CS is considered to be the same as a stream in the context of another CS, and hence the same MS object.

The multicast MoH stream was intended as an example of this case.
It may indeed go on continuously regardless of whether there are any 
receivers.

> Or putting it another way, if there is no CS in existence at a given point in time, I would assume there is no MS in existence. So when the last CSs terminates, do its associated MSs die, or can th…

Based on my prior comment, I think the MS can indeed exist without any 
CS referencing it. Of course in that case its most likely that it will 
not be recorded.

Treating it this way means that in a large deployment there might be 
hundreds of calls on hold, but the SRS could recognize that they are all 
receiving the same stream and so record it only once.

(And yes, I do know of systems that use multicast for MoH.)

	Thanks,
	Paul

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Tue, 23 Aug 2011 20:05:58 +0530

John,

One another example for MS exists across CS without hibernation is with
customer to multiple agent transfer in call center scenario wherein
customer un-mixed media stream is never stopped or put on hold till the
session is terminated by customer. In this scenario, Customer (single)
MS exists across CS but within any one of the CS at any given time, and
the scope of this MS is within CSG. Customer MS is the single RTP stream
which span across multiple CS and identified by its unique value.

Thanks
Partha

>Sent: Tuesday, August 23, 2011 7:51 PM
>To: Elwell, John
>> [JRE] Yes, each of the examples you give can be an MS. And I guess it
>is possible you could terminate an RS and start a new RS to resume
>recording of the same MS, so there might not be a 1:1 relationship
>between MS and RS.
>
>> None of these examples show why a MS can have a lifetime outside a CS
>- they all sound to me like they are implicitly within the context of a
>CS. So it doesn't answer my question about when a stream in the context
>of one CS is considered to be the same as a stream in the context of
>another CS, and hence the same MS object.
>
>> Or putting it another way, if there is no CS in existence at a given
>point in time, I would assume there is no MS in existence. So when the
>last CSs terminates, do its associated MSs die, or can they exist in a
>sort of hibernation and be revived when the next CS starts? Or in this
>situation, does the new CS have to have new MSs?
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 23 Aug 2011 17:49:52 +0200

> Sent: 23 August 2011 15:21
> To: Elwell, John
> > [JRE] Yes, each of the examples you give can be an MS. And 
> I guess it is possible you could terminate an RS and start a 
> new RS to resume recording of the same MS, so there might not 
> be a 1:1 relationship between MS and RS.
> 
> > None of these examples show why a MS can have a lifetime 
> outside a CS - they all sound to me like they are implicitly 
> within the context of a CS. So it doesn't answer my question 
> about when a stream in the context of one CS is considered to 
> be the same as a stream in the context of another CS, and 
> hence the same MS object.
> 
[JRE] OK, I understand now, but is the stream really of interest while there are no receivers, and when a receiver does appear again and it needs to be recorded again, what benefit arises from saying it is the same stream, as opposed to some new stream?

> 
> > Or putting it another way, if there is no CS in existence 
> at a given point in time, I would assume there is no MS in 
> existence. So when the last CSs terminates, do its associated 
> MSs die, or can they exist in a sort of hibernation and be 
> revived when the next CS starts? Or in this situation, does 
> the new CS have to have new MSs?
> 
[JRE] This requires the SRC to recognize that two or more participants in different CSs are really receiving the same stream. I don't know how often that will occur in practice. But then consider what happens at the SRS - does it record the stream only once, and as part of which CS recording? It would need to avoid the problem that, but deleting one CS recording, it also deletes a stream that other CS recordings depend on. On the other hand, if the stream is recorded independently of any CS recording, then what would trigger its deletion when all CS recordings that use it have been deleted (garbage collection)?

I can see that having a separate identifier for a stream could have benefits, but they seem like corner cases to me. It is a question of whether the WG feels the added overhead is justified.

John (as individual)

John Elwell

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 23 Aug 2011 13:49:22 -0700

Hi John,

>From all the examples, I do not yet see much value. The only case in
which I have seen some value is the case of an SRS that is handling many
recordings being able to detect that it is receiving multiple copies of
the same stream and optimizing to record only a single instance of it
(e.g. the multicast MoH case). For this specific case, it may be better
to add a mechanism to not record it at all. My thought is SRC
implementations may be smart enough to not include such streams in the
RS. But that is outside the scope of SIPREC. And in general, I am not
sure how likely it is that the SRCs will recognize this stream as being
the same, and use the same ID for it.
Using the same MS to represent the media from a participant before and
after a transfer does not seem necessary to me. As long as the media
before and after the transfer is associated with the same participant,
that seems sufficient to me.
My main hesitation with saying it is not necessary is that several
people seem to be making arguments for why it is necessary. My question
to them is, are you pointing out hypothetical use cases that you agree
are edge cases that can be ignored for now, or are these use cases
really of great interest to you.

Cheers,
Charles 

> From: Elwell, John [mailto:[email-masked]]
> Sent: Tuesday, August 23, 2011 8:50 AM
> To: Paul Kyzivat
[email-masked]
> [JRE] OK, I understand now, but is the stream really of interest while
there are no receivers, and
> when a receiver does appear again and it needs to be recorded again,
what benefit arises from saying
> it is the same stream, as opposed to some new stream?
> 
> >
> [JRE] This requires the SRC to recognize that two or more participants
in different CSs are really
> receiving the same stream. I don't know how often that will occur in
practice. But then consider what
> happens at the SRS - does it record the stream only once, and as part
of which CS recording? It would
> need to avoid the problem that, but deleting one CS recording, it also
deletes a stream that other CS
> recordings depend on. On the other hand, if the stream is recorded
independently of any CS recording,
> then what would trigger its deletion when all CS recordings that use
it have been deleted (garbage
> collection)?
> 
> I can see that having a separate identifier for a stream could have
benefits, but they seem like
> corner cases to me. It is a question of whether the WG feels the added
overhead is justified.

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 24 Aug 2011 09:52:42 +0200

Charles, 

> Sent: 23 August 2011 21:49
> To: Elwell, John; Paul Kyzivat
> Cc: Ravindran Parthasarathi; Leon Portman; [email-masked]
[JRE] Thanks for expressing more clearly my own thoughts.

> really of great interest to you.
[JRE] Yes, this is what we really need to know.

John (as individual)

> > Registered office: Brickhill Street, Willen Lake, Milton 
> Keynes, MK15
> 0DJ.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Aug 2011 15:22:37 -0400

> [JRE] Yes, this is what we really need to know.

I freely admit that for me these are hypothetical cases,
in that I don't have an actual implementation that I am speaking for.

But IMO, while use cases are very important, corner cases are also 
important. It is the corner cases that define the boundaries of what you 
are defining. (And that is true whether you decide the corner is "in" or 
"out".)

In this case, I think we are deciding whether to make a special case of 
MS, as contrasted to most of the other elements. The corner cases are 
handled it we treat it like other things, while the corner cases are 
excluded if we special case it. The argument for the special case is 
efficiency. But its not clear to me how much efficiency it affords - I'm 
inclined to think it isn't much.

So IMO this just adds an added argument in favor of *not* special casing 
MS, which would be my normal inclination in any case unless there were 
compelling arguments for why the optimization was needed.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 25 Aug 2011 08:55:04 +0200

Paul gives a good summary below of the situation concerning the need for a stream element. Based on Paul's arguments, I (as chair) would like to make a consensus call to keep the media stream as a separate object in the model and a separately identifiable element in XML, rather than realising the object solely through a reference to a labelled SDP media description. Even though this introduces an inefficiency for the vast majority of situations, there are potential corner cases where it would be useful. For other aspects of the model and its XML realisation we have erred on the side of flexibility rather than fine-tuned efficiency, and handling media stream in this way would be consistent with that principle. I don't think anyone has argued why the potential efficiency savings in taking a different approach are compelling.

>From my personal point of view I would have preferred to eliminate the element, but I can live with keeping it. However, I know I was not alone in preferring to eliminate it.

So if anyone still feels we should eliminate the stream element in XML, please say so in the next week (by 2011-09-01).

The editors are due to publish -04 by the end of the month, so I would suggest they retain the stream element in -04. If we don't achieve consensus to keep it, we will have to address it in -05.

John

John Elwell

> Sent: 24 August 2011 20:23
> To: Elwell, John
> Cc: Charles Eckel (eckelcu); Ravindran Parthasarathi; Leon 
> Portman; [email-masked]

---

From: Leon Portman <[email-masked]>
Date: Thu, 25 Aug 2011 10:10:48 +0300

I am for keeping it as separate object (as it today)

Regards

Leon

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Thursday, August 25, 2011 9:55 AM
To: Paul Kyzivat
Cc: Charles Eckel (eckelcu); Ravindran Parthasarathi; Leon Portman; [email-masked]
Subject: Consensus call - do we need a stream element?

John

John Elwell

> Cc: Charles Eckel (eckelcu); Ravindran Parthasarathi; Leon Portman; 
> [email-masked]
> >> which I have seen some value is the case of an SRS that is handling 
> >> many recordings being able to detect that it is receiving multiple 
> >> copies of the same stream and optimizing to record only a single
> instance of it
> >> (e.g. the multicast MoH case). For this specific case, it may be 
> >> better to add a mechanism to not record it at all. My thought is 
> >> SRC implementations may be smart enough to not include such
> streams in the
> >> sure how likely it is that the SRCs will recognize this stream as 
> >> being the same, and use the same ID for it.
> I freely admit that for me these are hypothetical cases, in that I 
> don't have an actual implementation that I am speaking for.
> 
> important. It is the corner cases that define the boundaries of what 
> you are defining. (And that is true whether you decide the corner is 
> "in" or
> "out".)
> 
> In this case, I think we are deciding whether to make a special case 
> of MS, as contrasted to most of the other elements. The corner cases 
> are handled it we treat it like other things, while the corner cases 
> are excluded if we special case it. The argument for the special case 
> is efficiency. But its not clear to me how much efficiency it affords 
> - I'm inclined to think it isn't much.
> 
> So IMO this just adds an added argument in favor of *not* special 
> casing MS, which would be my normal inclination in any case unless 
> there were compelling arguments for why the optimization was needed.
> 
> 	Thanks,
> 	Paul

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Thu, 25 Aug 2011 13:38:11 +0530

+1

Thanks
Partha

>From: Leon Portman [mailto:[email-masked]]
>Sent: Thursday, August 25, 2011 12:41 PM
>Cc: Charles Eckel (eckelcu); Ravindran Parthasarathi; [email-masked]
>Subject: RE: Consensus call - do we need a stream element?
>
>Paul gives a good summary below of the situation concerning the need
for
>a stream element. Based on Paul's arguments, I (as chair) would like to
>make a consensus call to keep the media stream as a separate object in
>the model and a separately identifiable element in XML, rather than
>realising the object solely through a reference to a labelled SDP media
>description. Even though this introduces an inefficiency for the vast
>majority of situations, there are potential corner cases where it would
>be useful. For other aspects of the model and its XML realisation we
>have erred on the side of flexibility rather than fine-tuned
efficiency,
>and handling media stream in this way would be consistent with that
>principle. I don't think anyone has argued why the potential efficiency
>savings in taking a different approach are compelling.
>
>From my personal point of view I would have preferred to eliminate the
>element, but I can live with keeping it. However, I know I was not
alone
>in preferring to eliminate it.
>
>So if anyone still feels we should eliminate the stream element in XML,
>please say so in the next week (by 2011-09-01).
>
>The editors are due to publish -04 by the end of the month, so I would
>suggest they retain the stream element in -04. If we don't achieve
>consensus to keep it, we will have to address it in -05.
>
>John
>
>John Elwell

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 25 Aug 2011 14:01:28 +0530

+1

Ram

> Subject: Re: [siprec] Consensus call - do we need a stream element?
> 
> for a stream element. Based on Paul's arguments, I (as chair) would
> like to make a consensus call to keep the media stream as a separate
> object in the model and a separately identifiable element in XML,
> rather than realising the object solely through a reference to a
> labelled SDP media description. Even though this introduces an
> inefficiency for the vast majority of situations, there are potential
> corner cases where it would be useful. For other aspects of the model
> and its XML realisation we have erred on the side of flexibility
rather
> than fine-tuned efficiency, and handling media stream in this way
would
> be consistent with that principle. I don't think anyone has argued why
> the potential efficiency savings in taking a different approach are
> compelling.
> 
> alone in preferring to eliminate it.
>