Subject: Re: [siprec] Does MS have life outside a particular CS? (was RE: comments on draft-ram-siprec-metadata-04)

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 11 May 2011 12:51:52 +0530

Hello All,

As per the discussions in last meeting and below mail thread it appears
that we would need global ID to take care of all the cases. However
there is a disagreement with some folks in having a unique ID. I would
request people to respond on this mail thread and take this issue to
closure.

If no one has issues, we will go with globally Unique ID for MS block.

Regards,
Ram

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Leon Portman
> Sent: Thursday, April 28, 2011 9:28 PM
> To: Paul Kyzivat (pkyzivat); Henry Lum
> Cc: [email-masked]
> Subject: Re: [siprec] Does MS have life outside a particular CS? (was
> RE: comments on draft-ram-siprec-metadata-04)
> 
> I agree that we should have all IDs to be globally unique.
> 
> Leon
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: Thursday, April 28, 2011 6:43 PM
> To: Henry Lum
> Cc: [email-masked]
> Subject: Re: [siprec] Does MS have life outside a particular CS? (was
> RE: comments on draft-ram-siprec-metadata-04)
> 
> 
> 
> On 4/28/2011 11:19 AM, Henry Lum wrote:
> > I agree it would be out of scope for two different SRCs to refer to
> > the same CS. The metadata model currently does not seem to prevent
> > such scenario, as long as there is a way to identify the same CS
> > across different SRC. The CS Identifier currently states that it is
a
> > unique identifier, and I don't think we should mandate that to be
> > globally unique across multiple SRCs like the CSG identifier.
> 
> Once you decide to have a "unique" id assigned by the SRC, its very
> little harder to make it globally unique rather than simply unique to
> an RS or an SRC. And there is very little benefit to the SRS to
> narrowing the scope either.
> 
> We only get to make this decision once. Its really hard to retrofit
> later to extend the scope. IMO all of the IDs should be globally
> unique.
> That gives us a lot more flexibility in how this evolves in the
future.
> 
> How we convey the id (as a URL, or something else) is another matter,
> and much less of a big deal. If the concern is how many bytes it
> consumes in the message then we can work on that.
> 
> In any case, while proposed mechanisms must satisfy the requirements,
> AFAIK there is no reason that a proposed mechanism cannot go beyond
the
> stated requirements. If there are multiple proposed mechanisms, and
one
> has ids more global than another, then people can decide which they
> like better. But the choice is only among what is proposed. So if
there
> are two philosophies in this regard, then maybe there had better be
two
> proposed mechanisms.
> 
> Or, I guess someone could propose a new requirement: "Unique IDs in
the
> mechanism MUST NOT be globally scoped - they MUST be locally scoped to
> an RS and duplicated across RSs". (I won't support that one.)
> 
>         Thanks,
>         Paul
> 
> > Regards,
> > Henry
> >
> >> -----Original Message-----
> >> From: Paul Kyzivat [mailto:[email-masked]]
> >> Sent: Wednesday, April 27, 2011 6:56 PM
> >> To: Henry Lum
> >> Cc: Parthasarathi R (partr); [email-masked]
> >> Subject: Re: [siprec] Does MS have life outside a particular CS?
> (was
> >> RE: comments on draft-ram-siprec-metadata-04)
> >>
> >>
> >>
> >> On 4/27/2011 5:01 PM, Henry Lum wrote:
> >>>> Presumably the RTP streams associated with the RS end when the RS
> >>> ends.
> >>>> That does not necessarily mean that the media stream of a CS also
> >> ends
> >>> at
> >>>> that time. It could be picked up again in a different RS by the
> > same
> >>> or
> >>>> different SRC.
> >>>
> >>> IIUC, a single CS is only mapped to a single SRC. If we have a
> media
> >>> stream of a CS picked by another SRC, then it should be a
different
> >> CS
> >>> but can be related to the same CS group.
> >>
> >> Two things:
> >>
> >> It could be the same SRC but two different RSs. (Perhaps it drops
> the
> >> RS during a long pause, or because the SRS crashed and restarted
and
> >> the SRC had to reconnect.)
> >>
> >> If there are two different SRCs, and they happen to know it is the
> > same
> >> CS (I'm not proposing *how* they know), it would be better to refer
> >> to the same CS.
> >>
> >> I'm not saying we should require SRCs to do such things - only that
> a
> >> design that permits this is better than one that does not.
> >>
> >>      Thanks,
> >>      Paul
> >>
> >>> Henry
> >>>
> >>>> -----Original Message-----
> >>>> From: [email-masked] [mailto:[email-masked]] On
> >>> Behalf
> >>>> Of Paul Kyzivat
> >>>> Sent: April-27-11 9:52 AM
> >>>> To: Parthasarathi R (partr)
> >>>> Cc: [email-masked]
> >>>> Subject: Re: [siprec] Does MS have life outside a particular CS?
> >> (was
> >>> RE:
> >>>> comments on draft-ram-siprec-metadata-04)
> >>>>
> >>>> There seems to be some confusion in this discussion about what a
> MS
> >>> is.
> >>>>
> >>>> On one hand there is an m-line in the SDP of the RS, and a
> >>> corresponding RTP
> >>>> stream.
> >>>>
> >>>> On another hand there is an m-line in a CS and a corresponding
RTP
> >>> stream.
> >>>>
> >>>> And then there is an MS described in the metadata conveyed over
> the
> >>> RS.
> >>>>
> >>>> And for both of the above, a single m-line might correspond to
> >>> different RTP
> >>>> streams over time, due to renegotiating the address and/or port
of
> >> the
> >>>> recipient, or by a different sender sending to the same port.
> >>>>
> >>>> There is a mapping between one or more RTP streams in the CS (or
> >>> multiple
> >>>> CSs?) and one or more RTP streams in the RS. The metadata
> hopefully
> >>>> describes that mapping.
> >>>>
> >>>> But perhaps we don't have full agreement on what sorts of
mappings
> >> are
> >>>> possible. Some that I think we allow are:
> >>>> - one CS RTP stream to one RS RTP stream.
> >>>> - multiple concurrent CS RTP streams mixed to one
> >>>>      RS RTP stream
> >>>> - multiple CS RTP streams sequentially mapped to the same
> >>>>      RS RTP stream
> >>>> ...
> >>>>
> >>>> Presumably the RTP streams associated with the RS end when the RS
> >>> ends.
> >>>> That does not necessarily mean that the media stream of a CS also
> >> ends
> >>> at
> >>>> that time. It could be picked up again in a different RS by the
> > same
> >>> or
> >>>> different SRC.
> >>>>
> >>>>    Thanks,
> >>>>    Paul
> >>>>
> >>>> On 4/27/2011 2:30 AM, Parthasarathi R (partr) wrote:
> >>>>> John,
> >>>>>
> >>>>> My intention is show the complexity in the metadata model in the
> >>>>> current form. Global unique id solves the issue but let us
> explore
> >>> for
> >>>>> better optimized solution with more local unique id if any
> exists.
> >>>>>
> >>>>> I have created another mail thread for adding the recording type
> >>>>> attribute which helps in most of the metadata blocks to have
> local
> >>>>> unique id rather than global unique id. Let us see how others
> >>>>> visualize that attribute.
> >>>>>
> >>>>> IMO, it may better to have globally unique id with the current
> >>>>> metadata model attributes. We may be able to add the normative
> >>>>> statement that "Media stream (MS) MUST be terminated when CS is
> >>>>> terminated" in the metadata but in reality, MS is within the
> scope
> >>> of
> >>>>> RS which is forced to delete for no reason. These sort will be
> >>>>> restrictive for few SRC implementation. For eg: RS may created
MS
> >>> with
> >>>>> RSVP which may not prefer to terminate the resource during RS
> >>>>> mid-session changes like CS changes even though intermediate
time
> >>> with
> >>>>> no media but the above normative statement forces to break those
> >> SRC
> >>>> implementation.
> >>>>>
> >>>>> Please read inline for more comments.
> >>>>>
> >>>>> Thanks
> >>>>> Partha
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: Elwell, John [mailto:[email-masked]]
> >>>>> Sent: Friday, April 22, 2011 1:48 AM
> >>>>> To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul Kyzivat
> >>>>> (pkyzivat)
> >>>>> Cc: [email-masked]
> >>>>> Subject: RE: Does MS have life outside a particular CS? (was RE:
> >>>>> [siprec] comments on draft-ram-siprec-metadata-04)
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Parthasarathi R (partr) [mailto:[email-masked]]
> >>>>>> Sent: 21 April 2011 17:20
> >>>>>> To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat
(pkyzivat)
> >>>>>> Cc: [email-masked]
> >>>>>> Subject: RE: Does MS have life outside a particular CS? (was
> >>>>>> RE: [siprec] comments on draft-ram-siprec-metadata-04)
> >>>>>>
> >>>>>> John,
> >>>>>>
> >>>>>> Please read inline.
> >>>>>>
> >>>>>> Thanks
> >>>>>> Partha
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Elwell, John [mailto:[email-masked]]
> >>>>>> Sent: Thursday, April 21, 2011 9:12 PM
> >>>>>> To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul
Kyzivat
> >>>>>> (pkyzivat)
> >>>>>> Cc: [email-masked]
> >>>>>> Subject: RE: Does MS have life outside a particular CS? (was
RE:
> >>>>>> [siprec] comments on draft-ram-siprec-metadata-04)
> >>>>>>
> >>>>>> Partha,
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Parthasarathi R (partr) [mailto:[email-masked]]
> >>>>>>> Sent: 21 April 2011 14:25
> >>>>>>> To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat
> (pkyzivat)
> >>>>>>> Cc: [email-masked]
> >>>>>>> Subject: RE: Does MS have life outside a particular CS? (was
> >>>>>>> RE: [siprec] comments on draft-ram-siprec-metadata-04)
> >>>>>>>
> >>>>>>> John,
> >>>>>>>
> >>>>>>> I could think of one usecase wherein MS is outside CS but
> within
> >>>>>>> single RS.  The usecase is multiple CS within single RS and
MS.
> >>> The
> >>>>>>> usecase is as follows:
> >>>>>>>
> >>>>>>> B2BUA acts as SRC. A, B, C are participants within single
> B2BUA.
> >> A
> >>>>>>> creates single RS for a CSG.
> >>>>>>>
> >>>>>>> 1) A calls B through B2BUA. B2BUA creates RS towards SRS with
> >>> CSG1,
> >>>>>>> CS1,
> >>>>>>> MS1 (A's media stream), MS2 (B's media stream), Participant1
as
> >> A&
> >>>>>>> Participant2 as B.
> >>>>>> [JRE] Why two media streams? Why not a single MS, with both A
> and
> >> B
> >>>>>> sending and receiving that MS?
> >>>>>> <Partha>    The media streams are un-mixed, MS1 points to RTP
> from
> >> A
> >>>>>> through label attribute in MS1 SDP, MS2 points to RTP from B
> >>> through
> >>>>>> label attribute in MS2 SDP</Partha>
> >>>>> [JRE] Reading the metadata model again, I think it does seem to
> >>> imply
> >>>>> two Media Stream objects if the two directions for a 2-party
call
> >>> are
> >>>>> sent unmixed (as two m-lines in the RS SDP), so I will concede
> > that
> >>> we
> >>>>> have two Media Stream objects here. I had been thinking of a
> >>> slightly
> >>>>> different model, where there is one Media Stream, but
> associations
> >>>>> between the Media Stream and Participants pointed to different
> >>> m-lines
> >>>>> in the RS SDP.
> >>>>>
> >>>>>>
> >>>>>>> 2) B connects with C through B2BUA
> >>>>>>> 3) B transfer the call of A&    B to C using REFER, B2BUA
> >>>>>> converts REFER
> >>>>>>
> >>>>>>> to RE-INVITE towards A&    C and A&    C are connected. B2BUA
> >>>>>> updates RS
> >>>>>>> with CS2, Participant1 as A&    participant2 as C, MS1(A's
> media
> >>>>>>> stream), MS2(C's media stream).
> >>>>>> [JRE] I would have expected, from my understanding of the
> > metadata
> >>>>>> model, that the CS2 would have a new MS, with both A and B
> > sending
> >>>>>> and
> >>>>>
> >>>>>> receiving that new MS.
> >>>>>>
> >>>>>> <Partha>    It is not mandatory because participant information
> >> will
> >>> be
> >>>>>> updated and pointing to the same m-line in RS with same label
> >>>>>> attribute.
> >>>>>>    From SRS perspective, the same media stream with the update
> in
> >> the
> >>>>>> participant name only. Say MS2 is stored as one record with B
as
> >>>>>> participant for T0 to T1 timelines and C as participant from T1
> > to
> >>> T2.
> >>>>>> </Partha>
> >>>>> [JRE] Or alternatively it could be modelled that when a new CS
> >>> starts
> >>>>> there is a new Media Stream object, still pointing to the same
> >>> m-line
> >>>>> in the RS SDP.
> >>>>>
> >>>>> <Partha>    The purpose of unique-id will go for toss here. The
> > same
> >>>>> media stream (MS) has unique id "id1" initially and later it
will
> >>> have "id2"
> >>>>> which will not be good for replay. Of course, MS life is always
> >>> within
> >>>>> RS in this scenario but not within CS. So, Unique Id within RS
> > will
> >>>>> serve the purpose</Partha>
> >>>>>
> >>>>>     This would avoid the need for a Media Stream object to
> survive
> >>>>> beyond the lifetime of a CS, and therefore allow local
> >>> identification.
> >>>>> While there is no CS in progress, the m-line would be disabled
> >> (port
> >>>>> 0) and would not be referenced by any Media Stream.
> >>>>>
> >>>>> <Partha>    RS m-line is not required to 0 because it shall
> change
> >>> into
> >>>>> "a=inactive" as well. There is no change in the resource
> >> reservation
> >>>>> in both SRC and SRS</Partha>
> >>>>>
> >>>>>>
> >>>>>>> There is no update on RS1, CSG1, MS1, MS2. MS2 will become MS2
> >>> with
> >>>>>>> the new association and in terms of format, it will associate
> >> with
> >>>>>>> <send>    tag.
> >>>>>>>
> >>>>>>> In the above scenario, MS have life outside CS but it is
within
> >>> RS.
> >>>>>> [JRE] I can see how it COULD work like that, but it is not
> >>> intuitive.
> >>>>>>
> >>>>>> <Partha>    In SIPREC solution, UPDATE message with CS2(session
> >>>>>> element) ,
> >>>>>> participant "C" element are received in SRS. This partial
update
> >> of
> >>>>>> UPDATE helps to make this scenario work. There is no change in
> >> term
> >>>>>> stream element or RS SDP</Partha>
> >>>>>>
> >>>>>> To me, a new CS means the existing media stream stops and a new
> >>> media
> >>>>>> stream is created.
> >>>>>>
> >>>>>> <Partha>    I'm interested knowing whether you propose that MS
> > MUST
> >>>>>> stop in case CS ends and the above scenario is outside the
scope
> >> of
> >>>> SIPREC?
> >>>>>> </Partha>
> >>>>>>
> >>>>>>> The
> >>>>>>> unique id shall be within RS scope as mentioned in IETF-80
> >>> meeting.
> >>>>>>> But in another situation, MS is outside the scope of RS but
> >>>>>> within CS
> >>>>>>> and the usecase is Multiple RS for single CS, details are
> >>>>>> as follows:
> >>>>>>>
> >>>>>>> A, B are pariticipants. A acts as SRC which tear down RS
> >>>>>> whenever hold
> >>>>>>
> >>>>>>> happens&    creates new RS when resume happens.
> >>>>>>>
> >>>>>>> 1) A calls B. A creates RS1 towards SRS with CS1, MS1 (A's
> media
> >>>>>>> stream), MS2 (B's Media stream),Participant1 as A&
> >>>>>> Participant2 as B.
> >>>>>> [JRE] Again, I would model this as a single MS, to which both A
> >> and
> >>> B
> >>>>>> contribute.
> >>>>>> <Partha>    Again, unmixed stream from A and B</Partha>
> >>>>>>> 2) A put B on hold. A tear down RS1.
> >>>>>>> 3) A resume B. A creates RS2 towards SRS with CS1, MS1 (A's
> > media
> >>>>>>> stream), MS2 (B's Media stream),Participant1 as A&
> >>>>>> Participant2 as B
> >>>>>>>
> >>>>>>> Here MS1&    MS2 needs to be same across RS to group media
> > streams
> >>>>>>> correctly. Please let me know your opinion here.
> >>>>>>
> >>>>>> [JRE] Although I disagree that we have two Media Streams here,
I
> >> do
> >>>>>> agree that the single Media Stream could be considered to
> survive
> >>> the
> >>>>>> hold/resume, and hence survive from RS1 to RS2. But the MS is
> >>> within
> >>>>>> the context of the same CS (CS1), and therefore this is outside
> >> the
> >>>>>> scope of this particular thread, which is asking whether an MS
> > can
> >>>>>> have a life outside a particular CS. In this case the MS
> > continues
> >>> to
> >>>>>> be associated with the CS, so I don't have a problem with that.
> >>>>>>
> >>>>>> <Partha>    I have 2nd example to illustrate MS have life
> outside
> >> RS.
> >>>>>> </Partha>
> >>>>>>
> >>>>>> So you have failed to convince me that an MS needs to have a
> life
> >>>>>> outside a CS.
> >>>>>>
> >>>>>> <Partha>    In case the above scenario-1 way of recording is
> >> outside
> >>>>>> the scope of SIPREC, I agree with you that MS does not have
life
> >>>>>> outside a
> >>>>>
> >>>>>> particular CS</Partha>
> >>>>> [JRE] I assume you are talking about the call transfer case. I
am
> >>> not
> >>>>> saying that use case is outside the scope of SIPREC. I am just
> >>> saying
> >>>>> that it can be modelled a different way, which may be
> advantageous
> >>> in
> >>>>> terms of the number of globally unique identifiers needed.
> >>>>>
> >>>>>
> >>>>> John (as individual)
> >>>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> John (as individual)
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> Having said that MS have life outside a particular CS, I
create
> >>>>>>> separate thread within unique how it shall be handled.
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>> Partha
> >>>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Elwell, John [mailto:[email-masked]]
> >>>>>>> Sent: Thursday, April 21, 2011 12:01 PM
> >>>>>>> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
> >>>>>>> Cc: Parthasarathi R (partr); [email-masked]
> >>>>>>> Subject: Does MS have life outside a particular CS? (was
> >>>>>> RE: [siprec]
> >>>>>>> comments on draft-ram-siprec-metadata-04)
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Ram Mohan R (rmohanr) [mailto:[email-masked]]
> >>>>>>>> Sent: 20 April 2011 18:08
> >>>>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat)
> >>>>>>>> Cc: Parthasarathi R (partr); [email-masked]
> >>>>>>>> Subject: RE: [siprec] comments on
draft-ram-siprec-metadata-04
> >>>>>>>>
> >>>>>>>> Hi John,
> >>>>>>>>
> >>>>>>>> Please see inline [RAM]
> >>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: Elwell, John [mailto:john.elwell@siemens-
> enterprise.com]
> >>>>>>>>> Sent: Wednesday, April 20, 2011 8:19 PM
> >>>>>>>>> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
> >>>>>>>>> Cc: Parthasarathi R (partr); [email-masked]
> >>>>>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-
> 04
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: Ram Mohan R (rmohanr) [mailto:[email-masked]]
> >>>>>>>>>> Sent: 20 April 2011 14:52
> >>>>>>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat)
> >>>>>>>>>> Cc: Parthasarathi R (partr); [email-masked]
> >>>>>>>>>> Subject: RE: [siprec] comments on
> > draft-ram-siprec-metadata-04
> >>>>>>>>>>
> >>>>>>>>>> John,
> >>>>>>>>>>
> >>>>>>>>>> I agree with you that normal cases RS will remain at
> >>>>>>> least for the
> >>>>>>>
> >>>>>>>>>> duration of CS. However it is common to have use cases
where
> >>>>>>>>> recording
> >>>>>>>>>> is done for first few mins of a CS and then stopped,
> >>>>>>>> re-started at a
> >>>>>>>>>> later point (e.g Recording of a company meeting where
> >>>>>>> you may want
> >>>>>>>> to
> >>>>>>>>>> record only portions of meeting).
> >>>>>>>>>>
> >>>>>>>>>> In any case, the point I like to high light here is, MS
> >>>>>>>> block could
> >>>>>>>>> be
> >>>>>>>>>> common across RS and even across CS[ due to consult
> >>>>>>>> transfer e.t.c].
> >>>>>>>>>> These use cases indicate the need to have a unique ID
> >>>>>>> for MS block
> >>>>>>>
> >>>>>>>>>> (similar to the UUID that we have defined in format) as
> >>>>>>> we cannot
> >>>>>>>>>> depend on neither CS ID or RS ID.
> >>>>>>>>> [JRE] I am having a hard time understanding the concept
> >>>>>>> of a single
> >>>>>>>>> Media Stream that survives across multiple CSs. For
> >>>>>>> example, in the
> >>>>>>>>> case of transfer, I would have thought new Media
> >>>>>> Streams would be
> >>>>>>>>> created.
> >>>>>>>>
> >>>>>>>> [RAM]
> >>>>>>>> Here is my thoughts.
> >>>>>>>> 1) There can be multiple RS per CS
> >>>>>>>> RS1 --- CS1--MS1
> >>>>>>>> RS2----CS1--MS1
> >>>>>>>> Examples are partial recording of CS (like recording parts
> >>>>>>> of meeting,
> >>>>>>>
> >>>>>>>> redundant recording where there are multiple SRCs recording
> >>>>>>> the same
> >>>>>>>> CS)
> >>>>>>> [JRE] Agreed. In this case MS1 is local to CS1.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> 2) There can be same Media Stream across multiple CS.
> >>>>>>>> RS1--- CS1--- MS1
> >>>>>>>> RS2--CS2--MS1
> >>>>>>>> Examples are Multicast MoH played to multiple end points who
> > are
> >>>>>>>> potentially part of disjoint CSs where each CS is recorded
> >>>>>>> as part of
> >>>>>>>> separate RS.
> >>>>>>>>
> >>>>>>>> Of course the above is arguable where the stream is same or
> >>>>>>> different.
> >>>>>>>> My view is since the UA (that supplies the Multicast MoH) and
> >> its
> >>>>>>>> media are same across all CS, I think it can be represented
> >>>>>>> as same MS
> >>>>>>>
> >>>>>>>> block.
> >>>>>>> [JRE] I would argue these are different MSs. I agree that a
> >> medium
> >>>>>>> such as music on hold might be sent, in synch, to multiple
> >>>>>>> participants in multiple CSs. In that particular situation
> >>>>>> there might
> >>>>>>
> >>>>>>> be some efficiency saving by calling it the same MS.
> >>>>>> However, I would
> >>>>>>> suggest (although this is not my field of expertise) it would
> >> make
> >>>>>>> life a lot harder for the SRS and its database. I would
> >>>>>> have expected
> >>>>>>> to want to record a complete CS (all its participants and
media
> >>>>>>> streams)  as a complete recording, which could be deleted,
> >>>>>> copied, and
> >>>>>>
> >>>>>>> so on without having to go looking for other objects that
> >> complete
> >>>>>>> that recording and are shared with other recordings. For
> >>>>>> example, if
> >>>>>>> you delete a recording, you would want to delete all its
> >>>>>> MSs, but not
> >>>>>>> those used by other recordings, although you would need a
> > garbage
> >>>>>>> collection mechanism to delete an MS recording when it is no
> >>> longer
> >>>>>>> used by any CS recordings. Rather ugly. Making a MS local to a
> > CS
> >>>>>>> would simplify all this.
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> However it is still possible to treat each as separate
> >>>>>>> stream in the
> >>>>>>>> model, in which case the information that it is the same MS
> >>>>>>> played by
> >>>>>>>> a UA to different CS will be lost. I don't know if there is
an
> >>>>>>>> interest to capture this level of detail and if it is of
> >>>>>> any use to
> >>>>>>>> SRS.
> >>>>>>> [JRE] I assume what you are saying here is not that
> >>>>>> information will
> >>>>>>> be lost, but that you will be unable to tell, without doing a
> >>>>>>> comparison, whether two different MSs played to participants
in
> >>> two
> >>>>>>> different CSs are identical or not for the particular time
> >>>>>> span that
> >>>>>>> is common. I don't see where such a requirement would come
> from.
> >>>>>>>
> >>>>>>> John (as individual)
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> siprec mailing list
> >>>> [email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/siprec
> >>>
> >>>
> >>>
> >
---------------------------------------------------------------------
> >> ----------------------------------------------
> >>> CONFIDENTIALITY NOTICE: This e-mail and any files attached may
> >> contain confidential and proprietary information of Alcatel-Lucent
> >> and/or its affiliated entities. Access by the intended recipient
> only
> >> is authorized. Any liability arising from any party acting, or
> >> refraining from acting, on any information contained in this e-mail
> >> is hereby excluded. If you are not the intended recipient, please
> >> notify the sender immediately, destroy the original transmission
and
> >> its attachments and do not disclose the contents to any other
> person,
> >> use it for any purpose, or store or copy the information in any
> medium.
> >> Copyright in this e-mail and any attachments belongs to
> >> Alcatel-Lucent and/or its affiliated entities.
> >>>
> >>>
> >
> >
> >
---------------------------------------------------------------------
> -
> > ---------------------------------------------
> > CONFIDENTIALITY NOTICE: This e-mail and any files attached may
> contain confidential and proprietary information of Alcatel-Lucent
> and/or its affiliated entities. Access by the intended recipient only
> is authorized. Any liability arising from any party acting, or
> refraining from acting, on any information contained in this e-mail is
> hereby excluded. If you are not the intended recipient, please notify
> the sender immediately, destroy the original transmission and its
> attachments and do not disclose the contents to any other person, use
> it for any purpose, or store or copy the information in any medium.
> Copyright in this e-mail and any attachments belongs to Alcatel-Lucent
> and/or its affiliated entities.
> >
> >
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 11 May 2011 19:18:44 +0530

If we consider MS as local to a Participant (as John was trying to
argue) there seems to be no need for a unique ID for MS since it can be
inferred from the Participant that can be uniquely identified.

The mail thread describes a use-case where multicast MoH played to a
number of participants and to the SRC is recorded. Can't the MoH source
be considered a Participant here?

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ram Mohan R (rmohanr)
|Sent: Wednesday, May 11, 2011 12:52 PM
|To: Leon Portman; Paul Kyzivat (pkyzivat); Henry Lum
|Cc: [email-masked]
|Subject: Re: [siprec] Does MS have life outside a particular CS? (was
RE:comments on draft-ram-siprec-
|metadata-04)
|
|Hello All,
|
|As per the discussions in last meeting and below mail thread it appears
|that we would need global ID to take care of all the cases. However
|there is a disagreement with some folks in having a unique ID. I would
|request people to respond on this mail thread and take this issue to
|closure.
|
|If no one has issues, we will go with globally Unique ID for MS block.
|
|Regards,
|Ram
|
|> -----Original Message-----
|> From: [email-masked] [mailto:[email-masked]] On
|> Behalf Of Leon Portman
|> Sent: Thursday, April 28, 2011 9:28 PM
|> To: Paul Kyzivat (pkyzivat); Henry Lum
|> Cc: [email-masked]
|> Subject: Re: [siprec] Does MS have life outside a particular CS? (was
|> RE: comments on draft-ram-siprec-metadata-04)
|>
|> I agree that we should have all IDs to be globally unique.
|>
|> Leon
|>
|> -----Original Message-----
|> From: [email-masked] [mailto:[email-masked]] On
|> Behalf Of Paul Kyzivat
|> Sent: Thursday, April 28, 2011 6:43 PM
|> To: Henry Lum
|> Cc: [email-masked]
|> Subject: Re: [siprec] Does MS have life outside a particular CS? (was
|> RE: comments on draft-ram-siprec-metadata-04)
|>
|>
|>
|> On 4/28/2011 11:19 AM, Henry Lum wrote:
|> > I agree it would be out of scope for two different SRCs to refer to
|> > the same CS. The metadata model currently does not seem to prevent
|> > such scenario, as long as there is a way to identify the same CS
|> > across different SRC. The CS Identifier currently states that it is
|a
|> > unique identifier, and I don't think we should mandate that to be
|> > globally unique across multiple SRCs like the CSG identifier.
|>
|> Once you decide to have a "unique" id assigned by the SRC, its very
|> little harder to make it globally unique rather than simply unique to
|> an RS or an SRC. And there is very little benefit to the SRS to
|> narrowing the scope either.
|>
|> We only get to make this decision once. Its really hard to retrofit
|> later to extend the scope. IMO all of the IDs should be globally
|> unique.
|> That gives us a lot more flexibility in how this evolves in the
|future.
|>
|> How we convey the id (as a URL, or something else) is another matter,
|> and much less of a big deal. If the concern is how many bytes it
|> consumes in the message then we can work on that.
|>
|> In any case, while proposed mechanisms must satisfy the requirements,
|> AFAIK there is no reason that a proposed mechanism cannot go beyond
|the
|> stated requirements. If there are multiple proposed mechanisms, and
|one
|> has ids more global than another, then people can decide which they
|> like better. But the choice is only among what is proposed. So if
|there
|> are two philosophies in this regard, then maybe there had better be
|two
|> proposed mechanisms.
|>
|> Or, I guess someone could propose a new requirement: "Unique IDs in
|the
|> mechanism MUST NOT be globally scoped - they MUST be locally scoped
to
|> an RS and duplicated across RSs". (I won't support that one.)
|>
|>         Thanks,
|>         Paul
|>
|> > Regards,
|> > Henry
|> >
|> >> -----Original Message-----
|> >> From: Paul Kyzivat [mailto:[email-masked]]
|> >> Sent: Wednesday, April 27, 2011 6:56 PM
|> >> To: Henry Lum
|> >> Cc: Parthasarathi R (partr); [email-masked]
|> >> Subject: Re: [siprec] Does MS have life outside a particular CS?
|> (was
|> >> RE: comments on draft-ram-siprec-metadata-04)
|> >>
|> >>
|> >>
|> >> On 4/27/2011 5:01 PM, Henry Lum wrote:
|> >>>> Presumably the RTP streams associated with the RS end when the
RS
|> >>> ends.
|> >>>> That does not necessarily mean that the media stream of a CS
also
|> >> ends
|> >>> at
|> >>>> that time. It could be picked up again in a different RS by the
|> > same
|> >>> or
|> >>>> different SRC.
|> >>>
|> >>> IIUC, a single CS is only mapped to a single SRC. If we have a
|> media
|> >>> stream of a CS picked by another SRC, then it should be a
|different
|> >> CS
|> >>> but can be related to the same CS group.
|> >>
|> >> Two things:
|> >>
|> >> It could be the same SRC but two different RSs. (Perhaps it drops
|> the
|> >> RS during a long pause, or because the SRS crashed and restarted
|and
|> >> the SRC had to reconnect.)
|> >>
|> >> If there are two different SRCs, and they happen to know it is the
|> > same
|> >> CS (I'm not proposing *how* they know), it would be better to
refer
|> >> to the same CS.
|> >>
|> >> I'm not saying we should require SRCs to do such things - only
that
|> a
|> >> design that permits this is better than one that does not.
|> >>
|> >>      Thanks,
|> >>      Paul
|> >>
|> >>> Henry
|> >>>
|> >>>> -----Original Message-----
|> >>>> From: [email-masked] [mailto:[email-masked]]
On
|> >>> Behalf
|> >>>> Of Paul Kyzivat
|> >>>> Sent: April-27-11 9:52 AM
|> >>>> To: Parthasarathi R (partr)
|> >>>> Cc: [email-masked]
|> >>>> Subject: Re: [siprec] Does MS have life outside a particular CS?
|> >> (was
|> >>> RE:
|> >>>> comments on draft-ram-siprec-metadata-04)
|> >>>>
|> >>>> There seems to be some confusion in this discussion about what a
|> MS
|> >>> is.
|> >>>>
|> >>>> On one hand there is an m-line in the SDP of the RS, and a
|> >>> corresponding RTP
|> >>>> stream.
|> >>>>
|> >>>> On another hand there is an m-line in a CS and a corresponding
|RTP
|> >>> stream.
|> >>>>
|> >>>> And then there is an MS described in the metadata conveyed over
|> the
|> >>> RS.
|> >>>>
|> >>>> And for both of the above, a single m-line might correspond to
|> >>> different RTP
|> >>>> streams over time, due to renegotiating the address and/or port
|of
|> >> the
|> >>>> recipient, or by a different sender sending to the same port.
|> >>>>
|> >>>> There is a mapping between one or more RTP streams in the CS (or
|> >>> multiple
|> >>>> CSs?) and one or more RTP streams in the RS. The metadata
|> hopefully
|> >>>> describes that mapping.
|> >>>>
|> >>>> But perhaps we don't have full agreement on what sorts of
|mappings
|> >> are
|> >>>> possible. Some that I think we allow are:
|> >>>> - one CS RTP stream to one RS RTP stream.
|> >>>> - multiple concurrent CS RTP streams mixed to one
|> >>>>      RS RTP stream
|> >>>> - multiple CS RTP streams sequentially mapped to the same
|> >>>>      RS RTP stream
|> >>>> ...
|> >>>>
|> >>>> Presumably the RTP streams associated with the RS end when the
RS
|> >>> ends.
|> >>>> That does not necessarily mean that the media stream of a CS
also
|> >> ends
|> >>> at
|> >>>> that time. It could be picked up again in a different RS by the
|> > same
|> >>> or
|> >>>> different SRC.
|> >>>>
|> >>>>    Thanks,
|> >>>>    Paul
|> >>>>
|> >>>> On 4/27/2011 2:30 AM, Parthasarathi R (partr) wrote:
|> >>>>> John,
|> >>>>>
|> >>>>> My intention is show the complexity in the metadata model in
the
|> >>>>> current form. Global unique id solves the issue but let us
|> explore
|> >>> for
|> >>>>> better optimized solution with more local unique id if any
|> exists.
|> >>>>>
|> >>>>> I have created another mail thread for adding the recording
type
|> >>>>> attribute which helps in most of the metadata blocks to have
|> local
|> >>>>> unique id rather than global unique id. Let us see how others
|> >>>>> visualize that attribute.
|> >>>>>
|> >>>>> IMO, it may better to have globally unique id with the current
|> >>>>> metadata model attributes. We may be able to add the normative
|> >>>>> statement that "Media stream (MS) MUST be terminated when CS is
|> >>>>> terminated" in the metadata but in reality, MS is within the
|> scope
|> >>> of
|> >>>>> RS which is forced to delete for no reason. These sort will be
|> >>>>> restrictive for few SRC implementation. For eg: RS may created
|MS
|> >>> with
|> >>>>> RSVP which may not prefer to terminate the resource during RS
|> >>>>> mid-session changes like CS changes even though intermediate
|time
|> >>> with
|> >>>>> no media but the above normative statement forces to break
those
|> >> SRC
|> >>>> implementation.
|> >>>>>
|> >>>>> Please read inline for more comments.
|> >>>>>
|> >>>>> Thanks
|> >>>>> Partha
|> >>>>>
|> >>>>> -----Original Message-----
|> >>>>> From: Elwell, John [mailto:[email-masked]]
|> >>>>> Sent: Friday, April 22, 2011 1:48 AM
|> >>>>> To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul
Kyzivat
|> >>>>> (pkyzivat)
|> >>>>> Cc: [email-masked]
|> >>>>> Subject: RE: Does MS have life outside a particular CS? (was
RE:
|> >>>>> [siprec] comments on draft-ram-siprec-metadata-04)
|> >>>>>
|> >>>>>
|> >>>>>
|> >>>>>> -----Original Message-----
|> >>>>>> From: Parthasarathi R (partr) [mailto:[email-masked]]
|> >>>>>> Sent: 21 April 2011 17:20
|> >>>>>> To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat
|(pkyzivat)
|> >>>>>> Cc: [email-masked]
|> >>>>>> Subject: RE: Does MS have life outside a particular CS? (was
|> >>>>>> RE: [siprec] comments on draft-ram-siprec-metadata-04)
|> >>>>>>
|> >>>>>> John,
|> >>>>>>
|> >>>>>> Please read inline.
|> >>>>>>
|> >>>>>> Thanks
|> >>>>>> Partha
|> >>>>>>
|> >>>>>> -----Original Message-----
|> >>>>>> From: Elwell, John [mailto:[email-masked]]
|> >>>>>> Sent: Thursday, April 21, 2011 9:12 PM
|> >>>>>> To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul
|Kyzivat
|> >>>>>> (pkyzivat)
|> >>>>>> Cc: [email-masked]
|> >>>>>> Subject: RE: Does MS have life outside a particular CS? (was
|RE:
|> >>>>>> [siprec] comments on draft-ram-siprec-metadata-04)
|> >>>>>>
|> >>>>>> Partha,
|> >>>>>>
|> >>>>>>> -----Original Message-----
|> >>>>>>> From: Parthasarathi R (partr) [mailto:[email-masked]]
|> >>>>>>> Sent: 21 April 2011 14:25
|> >>>>>>> To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat
|> (pkyzivat)
|> >>>>>>> Cc: [email-masked]
|> >>>>>>> Subject: RE: Does MS have life outside a particular CS? (was
|> >>>>>>> RE: [siprec] comments on draft-ram-siprec-metadata-04)
|> >>>>>>>
|> >>>>>>> John,
|> >>>>>>>
|> >>>>>>> I could think of one usecase wherein MS is outside CS but
|> within
|> >>>>>>> single RS.  The usecase is multiple CS within single RS and
|MS.
|> >>> The
|> >>>>>>> usecase is as follows:
|> >>>>>>>
|> >>>>>>> B2BUA acts as SRC. A, B, C are participants within single
|> B2BUA.
|> >> A
|> >>>>>>> creates single RS for a CSG.
|> >>>>>>>
|> >>>>>>> 1) A calls B through B2BUA. B2BUA creates RS towards SRS with
|> >>> CSG1,
|> >>>>>>> CS1,
|> >>>>>>> MS1 (A's media stream), MS2 (B's media stream), Participant1
|as
|> >> A&
|> >>>>>>> Participant2 as B.
|> >>>>>> [JRE] Why two media streams? Why not a single MS, with both A
|> and
|> >> B
|> >>>>>> sending and receiving that MS?
|> >>>>>> <Partha>    The media streams are un-mixed, MS1 points to RTP
|> from
|> >> A
|> >>>>>> through label attribute in MS1 SDP, MS2 points to RTP from B
|> >>> through
|> >>>>>> label attribute in MS2 SDP</Partha>
|> >>>>> [JRE] Reading the metadata model again, I think it does seem to
|> >>> imply
|> >>>>> two Media Stream objects if the two directions for a 2-party
|call
|> >>> are
|> >>>>> sent unmixed (as two m-lines in the RS SDP), so I will concede
|> > that
|> >>> we
|> >>>>> have two Media Stream objects here. I had been thinking of a
|> >>> slightly
|> >>>>> different model, where there is one Media Stream, but
|> associations
|> >>>>> between the Media Stream and Participants pointed to different
|> >>> m-lines
|> >>>>> in the RS SDP.
|> >>>>>
|> >>>>>>
|> >>>>>>> 2) B connects with C through B2BUA
|> >>>>>>> 3) B transfer the call of A&    B to C using REFER, B2BUA
|> >>>>>> converts REFER
|> >>>>>>
|> >>>>>>> to RE-INVITE towards A&    C and A&    C are connected. B2BUA
|> >>>>>> updates RS
|> >>>>>>> with CS2, Participant1 as A&    participant2 as C, MS1(A's
|> media
|> >>>>>>> stream), MS2(C's media stream).
|> >>>>>> [JRE] I would have expected, from my understanding of the
|> > metadata
|> >>>>>> model, that the CS2 would have a new MS, with both A and B
|> > sending
|> >>>>>> and
|> >>>>>
|> >>>>>> receiving that new MS.
|> >>>>>>
|> >>>>>> <Partha>    It is not mandatory because participant
information
|> >> will
|> >>> be
|> >>>>>> updated and pointing to the same m-line in RS with same label
|> >>>>>> attribute.
|> >>>>>>    From SRS perspective, the same media stream with the update
|> in
|> >> the
|> >>>>>> participant name only. Say MS2 is stored as one record with B
|as
|> >>>>>> participant for T0 to T1 timelines and C as participant from
T1
|> > to
|> >>> T2.
|> >>>>>> </Partha>
|> >>>>> [JRE] Or alternatively it could be modelled that when a new CS
|> >>> starts
|> >>>>> there is a new Media Stream object, still pointing to the same
|> >>> m-line
|> >>>>> in the RS SDP.
|> >>>>>
|> >>>>> <Partha>    The purpose of unique-id will go for toss here. The
|> > same
|> >>>>> media stream (MS) has unique id "id1" initially and later it
|will
|> >>> have "id2"
|> >>>>> which will not be good for replay. Of course, MS life is always
|> >>> within
|> >>>>> RS in this scenario but not within CS. So, Unique Id within RS
|> > will
|> >>>>> serve the purpose</Partha>
|> >>>>>
|> >>>>>     This would avoid the need for a Media Stream object to
|> survive
|> >>>>> beyond the lifetime of a CS, and therefore allow local
|> >>> identification.
|> >>>>> While there is no CS in progress, the m-line would be disabled
|> >> (port
|> >>>>> 0) and would not be referenced by any Media Stream.
|> >>>>>
|> >>>>> <Partha>    RS m-line is not required to 0 because it shall
|> change
|> >>> into
|> >>>>> "a=inactive" as well. There is no change in the resource
|> >> reservation
|> >>>>> in both SRC and SRS</Partha>
|> >>>>>
|> >>>>>>
|> >>>>>>> There is no update on RS1, CSG1, MS1, MS2. MS2 will become
MS2
|> >>> with
|> >>>>>>> the new association and in terms of format, it will associate
|> >> with
|> >>>>>>> <send>    tag.
|> >>>>>>>
|> >>>>>>> In the above scenario, MS have life outside CS but it is
|within
|> >>> RS.
|> >>>>>> [JRE] I can see how it COULD work like that, but it is not
|> >>> intuitive.
|> >>>>>>
|> >>>>>> <Partha>    In SIPREC solution, UPDATE message with
CS2(session
|> >>>>>> element) ,
|> >>>>>> participant "C" element are received in SRS. This partial
|update
|> >> of
|> >>>>>> UPDATE helps to make this scenario work. There is no change in
|> >> term
|> >>>>>> stream element or RS SDP</Partha>
|> >>>>>>
|> >>>>>> To me, a new CS means the existing media stream stops and a
new
|> >>> media
|> >>>>>> stream is created.
|> >>>>>>
|> >>>>>> <Partha>    I'm interested knowing whether you propose that MS
|> > MUST
|> >>>>>> stop in case CS ends and the above scenario is outside the
|scope
|> >> of
|> >>>> SIPREC?
|> >>>>>> </Partha>
|> >>>>>>
|> >>>>>>> The
|> >>>>>>> unique id shall be within RS scope as mentioned in IETF-80
|> >>> meeting.
|> >>>>>>> But in another situation, MS is outside the scope of RS but
|> >>>>>> within CS
|> >>>>>>> and the usecase is Multiple RS for single CS, details are
|> >>>>>> as follows:
|> >>>>>>>
|> >>>>>>> A, B are pariticipants. A acts as SRC which tear down RS
|> >>>>>> whenever hold
|> >>>>>>
|> >>>>>>> happens&    creates new RS when resume happens.
|> >>>>>>>
|> >>>>>>> 1) A calls B. A creates RS1 towards SRS with CS1, MS1 (A's
|> media
|> >>>>>>> stream), MS2 (B's Media stream),Participant1 as A&
|> >>>>>> Participant2 as B.
|> >>>>>> [JRE] Again, I would model this as a single MS, to which both
A
|> >> and
|> >>> B
|> >>>>>> contribute.
|> >>>>>> <Partha>    Again, unmixed stream from A and B</Partha>
|> >>>>>>> 2) A put B on hold. A tear down RS1.
|> >>>>>>> 3) A resume B. A creates RS2 towards SRS with CS1, MS1 (A's
|> > media
|> >>>>>>> stream), MS2 (B's Media stream),Participant1 as A&
|> >>>>>> Participant2 as B
|> >>>>>>>
|> >>>>>>> Here MS1&    MS2 needs to be same across RS to group media
|> > streams
|> >>>>>>> correctly. Please let me know your opinion here.
|> >>>>>>
|> >>>>>> [JRE] Although I disagree that we have two Media Streams here,
|I
|> >> do
|> >>>>>> agree that the single Media Stream could be considered to
|> survive
|> >>> the
|> >>>>>> hold/resume, and hence survive from RS1 to RS2. But the MS is
|> >>> within
|> >>>>>> the context of the same CS (CS1), and therefore this is
outside
|> >> the
|> >>>>>> scope of this particular thread, which is asking whether an MS
|> > can
|> >>>>>> have a life outside a particular CS. In this case the MS
|> > continues
|> >>> to
|> >>>>>> be associated with the CS, so I don't have a problem with
that.
|> >>>>>>
|> >>>>>> <Partha>    I have 2nd example to illustrate MS have life
|> outside
|> >> RS.
|> >>>>>> </Partha>
|> >>>>>>
|> >>>>>> So you have failed to convince me that an MS needs to have a
|> life
|> >>>>>> outside a CS.
|> >>>>>>
|> >>>>>> <Partha>    In case the above scenario-1 way of recording is
|> >> outside
|> >>>>>> the scope of SIPREC, I agree with you that MS does not have
|life
|> >>>>>> outside a
|> >>>>>
|> >>>>>> particular CS</Partha>
|> >>>>> [JRE] I assume you are talking about the call transfer case. I
|am
|> >>> not
|> >>>>> saying that use case is outside the scope of SIPREC. I am just
|> >>> saying
|> >>>>> that it can be modelled a different way, which may be
|> advantageous
|> >>> in
|> >>>>> terms of the number of globally unique identifiers needed.
|> >>>>>
|> >>>>>
|> >>>>> John (as individual)
|> >>>>>
|> >>>>>
|> >>>>>
|> >>>>>>
|> >>>>>> John (as individual)
|> >>>>>>
|> >>>>>>
|> >>>>>>>
|> >>>>>>> Having said that MS have life outside a particular CS, I
|create
|> >>>>>>> separate thread within unique how it shall be handled.
|> >>>>>>>
|> >>>>>>> Thanks
|> >>>>>>> Partha
|> >>>>>>>
|> >>>>>>> -----Original Message-----
|> >>>>>>> From: Elwell, John
[mailto:[email-masked]]
|> >>>>>>> Sent: Thursday, April 21, 2011 12:01 PM
|> >>>>>>> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
|> >>>>>>> Cc: Parthasarathi R (partr); [email-masked]
|> >>>>>>> Subject: Does MS have life outside a particular CS? (was
|> >>>>>> RE: [siprec]
|> >>>>>>> comments on draft-ram-siprec-metadata-04)
|> >>>>>>>
|> >>>>>>>
|> >>>>>>>
|> >>>>>>>> -----Original Message-----
|> >>>>>>>> From: Ram Mohan R (rmohanr) [mailto:[email-masked]]
|> >>>>>>>> Sent: 20 April 2011 18:08
|> >>>>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat)
|> >>>>>>>> Cc: Parthasarathi R (partr); [email-masked]
|> >>>>>>>> Subject: RE: [siprec] comments on
|draft-ram-siprec-metadata-04
|> >>>>>>>>
|> >>>>>>>> Hi John,
|> >>>>>>>>
|> >>>>>>>> Please see inline [RAM]
|> >>>>>>>>
|> >>>>>>>>> -----Original Message-----
|> >>>>>>>>> From: Elwell, John [mailto:john.elwell@siemens-
|> enterprise.com]
|> >>>>>>>>> Sent: Wednesday, April 20, 2011 8:19 PM
|> >>>>>>>>> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
|> >>>>>>>>> Cc: Parthasarathi R (partr); [email-masked]
|> >>>>>>>>> Subject: RE: [siprec] comments on
draft-ram-siprec-metadata-
|> 04
|> >>>>>>>>>
|> >>>>>>>>>
|> >>>>>>>>>
|> >>>>>>>>>> -----Original Message-----
|> >>>>>>>>>> From: Ram Mohan R (rmohanr) [mailto:[email-masked]]
|> >>>>>>>>>> Sent: 20 April 2011 14:52
|> >>>>>>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat)
|> >>>>>>>>>> Cc: Parthasarathi R (partr); [email-masked]
|> >>>>>>>>>> Subject: RE: [siprec] comments on
|> > draft-ram-siprec-metadata-04
|> >>>>>>>>>>
|> >>>>>>>>>> John,
|> >>>>>>>>>>
|> >>>>>>>>>> I agree with you that normal cases RS will remain at
|> >>>>>>> least for the
|> >>>>>>>
|> >>>>>>>>>> duration of CS. However it is common to have use cases
|where
|> >>>>>>>>> recording
|> >>>>>>>>>> is done for first few mins of a CS and then stopped,
|> >>>>>>>> re-started at a
|> >>>>>>>>>> later point (e.g Recording of a company meeting where
|> >>>>>>> you may want
|> >>>>>>>> to
|> >>>>>>>>>> record only portions of meeting).
|> >>>>>>>>>>
|> >>>>>>>>>> In any case, the point I like to high light here is, MS
|> >>>>>>>> block could
|> >>>>>>>>> be
|> >>>>>>>>>> common across RS and even across CS[ due to consult
|> >>>>>>>> transfer e.t.c].
|> >>>>>>>>>> These use cases indicate the need to have a unique ID
|> >>>>>>> for MS block
|> >>>>>>>
|> >>>>>>>>>> (similar to the UUID that we have defined in format) as
|> >>>>>>> we cannot
|> >>>>>>>>>> depend on neither CS ID or RS ID.
|> >>>>>>>>> [JRE] I am having a hard time understanding the concept
|> >>>>>>> of a single
|> >>>>>>>>> Media Stream that survives across multiple CSs. For
|> >>>>>>> example, in the
|> >>>>>>>>> case of transfer, I would have thought new Media
|> >>>>>> Streams would be
|> >>>>>>>>> created.
|> >>>>>>>>
|> >>>>>>>> [RAM]
|> >>>>>>>> Here is my thoughts.
|> >>>>>>>> 1) There can be multiple RS per CS
|> >>>>>>>> RS1 --- CS1--MS1
|> >>>>>>>> RS2----CS1--MS1
|> >>>>>>>> Examples are partial recording of CS (like recording parts
|> >>>>>>> of meeting,
|> >>>>>>>
|> >>>>>>>> redundant recording where there are multiple SRCs recording
|> >>>>>>> the same
|> >>>>>>>> CS)
|> >>>>>>> [JRE] Agreed. In this case MS1 is local to CS1.
|> >>>>>>>
|> >>>>>>>>
|> >>>>>>>> 2) There can be same Media Stream across multiple CS.
|> >>>>>>>> RS1--- CS1--- MS1
|> >>>>>>>> RS2--CS2--MS1
|> >>>>>>>> Examples are Multicast MoH played to multiple end points who
|> > are
|> >>>>>>>> potentially part of disjoint CSs where each CS is recorded
|> >>>>>>> as part of
|> >>>>>>>> separate RS.
|> >>>>>>>>
|> >>>>>>>> Of course the above is arguable where the stream is same or
|> >>>>>>> different.
|> >>>>>>>> My view is since the UA (that supplies the Multicast MoH)
and
|> >> its
|> >>>>>>>> media are same across all CS, I think it can be represented
|> >>>>>>> as same MS
|> >>>>>>>
|> >>>>>>>> block.
|> >>>>>>> [JRE] I would argue these are different MSs. I agree that a
|> >> medium
|> >>>>>>> such as music on hold might be sent, in synch, to multiple
|> >>>>>>> participants in multiple CSs. In that particular situation
|> >>>>>> there might
|> >>>>>>
|> >>>>>>> be some efficiency saving by calling it the same MS.
|> >>>>>> However, I would
|> >>>>>>> suggest (although this is not my field of expertise) it would
|> >> make
|> >>>>>>> life a lot harder for the SRS and its database. I would
|> >>>>>> have expected
|> >>>>>>> to want to record a complete CS (all its participants and
|media
|> >>>>>>> streams)  as a complete recording, which could be deleted,
|> >>>>>> copied, and
|> >>>>>>
|> >>>>>>> so on without having to go looking for other objects that
|> >> complete
|> >>>>>>> that recording and are shared with other recordings. For
|> >>>>>> example, if
|> >>>>>>> you delete a recording, you would want to delete all its
|> >>>>>> MSs, but not
|> >>>>>>> those used by other recordings, although you would need a
|> > garbage
|> >>>>>>> collection mechanism to delete an MS recording when it is no
|> >>> longer
|> >>>>>>> used by any CS recordings. Rather ugly. Making a MS local to
a
|> > CS
|> >>>>>>> would simplify all this.
|> >>>>>>>
|> >>>>>>>>
|> >>>>>>>>
|> >>>>>>>> However it is still possible to treat each as separate
|> >>>>>>> stream in the
|> >>>>>>>> model, in which case the information that it is the same MS
|> >>>>>>> played by
|> >>>>>>>> a UA to different CS will be lost. I don't know if there is
|an
|> >>>>>>>> interest to capture this level of detail and if it is of
|> >>>>>> any use to
|> >>>>>>>> SRS.
|> >>>>>>> [JRE] I assume what you are saying here is not that
|> >>>>>> information will
|> >>>>>>> be lost, but that you will be unable to tell, without doing a
|> >>>>>>> comparison, whether two different MSs played to participants
|in
|> >>> two
|> >>>>>>> different CSs are identical or not for the particular time
|> >>>>>> span that
|> >>>>>>> is common. I don't see where such a requirement would come
|> from.
|> >>>>>>>
|> >>>>>>> John (as individual)
|> >>>>>>>
|> >>>>>>>
|> >>>>>>
|> >>>>>
|> >>>> _______________________________________________
|> >>>> siprec mailing list
|> >>>> [email-masked]
|> >>>> https://www.ietf.org/mailman/listinfo/siprec
|> >>>
|> >>>
|> >>>
|> >
|---------------------------------------------------------------------
|> >> ----------------------------------------------
|> >>> CONFIDENTIALITY NOTICE: This e-mail and any files attached may
|> >> contain confidential and proprietary information of Alcatel-Lucent
|> >> and/or its affiliated entities. Access by the intended recipient
|> only
|> >> is authorized. Any liability arising from any party acting, or
|> >> refraining from acting, on any information contained in this
e-mail
|> >> is hereby excluded. If you are not the intended recipient, please
|> >> notify the sender immediately, destroy the original transmission
|and
|> >> its attachments and do not disclose the contents to any other
|> person,
|> >> use it for any purpose, or store or copy the information in any
|> medium.
|> >> Copyright in this e-mail and any attachments belongs to
|> >> Alcatel-Lucent and/or its affiliated entities.
|> >>>
|> >>>
|> >
|> >
|> >
|---------------------------------------------------------------------
|> -
|> > ---------------------------------------------
|> > CONFIDENTIALITY NOTICE: This e-mail and any files attached may
|> contain confidential and proprietary information of Alcatel-Lucent
|> and/or its affiliated entities. Access by the intended recipient only
|> is authorized. Any liability arising from any party acting, or
|> refraining from acting, on any information contained in this e-mail
is
|> hereby excluded. If you are not the intended recipient, please notify
|> the sender immediately, destroy the original transmission and its
|> attachments and do not disclose the contents to any other person, use
|> it for any purpose, or store or copy the information in any medium.
|> Copyright in this e-mail and any attachments belongs to
Alcatel-Lucent
|> and/or its affiliated entities.
|> >
|> >
|> _______________________________________________
|> siprec mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/siprec
|> _______________________________________________
|> siprec mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/siprec
|_______________________________________________
|siprec mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/siprec

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 11 May 2011 11:00:41 -0700

I also don't see a need to use another unique ID for a media stream as
the relationship can be inferred by participants and CS.

As for things like MOH, I tend to agree that we need to have an
automated participant to deliver media as a dialog to a use which is the
other participant. Having an explicit relationship for dialogs like this
helps us to visualize who the participant is interacting with during the
lifetime of the CS (ie. how many times did the participant was put on
hold?). 

On the other hand, if we have a conference mixer that generates a mixed
media stream to all the conference participants, then do we need a mixer
participant that contributes to this mixed output? My initial reaction
is no, meaning a mixer can be implied in the relationship whenever a
media stream is sent to multiple participants, but we can also allow
someone to explicitly model this with a mixer participant.

Regards,
Henry

> From: Muthu ArulMozhi Perumal (mperumal) [mailto:[email-masked]]
> Sent: Wednesday, May 11, 2011 9:49 AM
> To: Ram Mohan R (rmohanr); Leon Portman; Paul Kyzivat (pkyzivat);
Henry
> Lum
> Cc: [email-masked]
> Subject: RE: [siprec] Does MS have life outside a particular CS? (was
> RE:comments on draft-ram-siprec-metadata-04)
> 
> |> >>>>> From: Elwell, John
> |> >>>>>>> RE: [siprec] comments on draft-ram-siprec-metadata-04)

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 12 May 2011 06:09:48 +0530

Henry,

|On the other hand, if we have a conference mixer that generates a 
|mixed media stream to all the conference participants, then do we
|need a mixer participant that contributes to this mixed output?

I think it depends if the mixer is SRC or not. If the mixer is SRC (case
2 in the metadata draft) we don't need a mixer participant. If the mixer
is not (case 4 in the metadata draft) then we do -- this could be
modeled by associating the conference participants with the mixer
participant and by visualizing that the media streams generated by the
conference participants contribute the combined media stream generated
by the mixer participant (analogous to how RTP models a mixer).

Muthu

|-----Original Message-----
|From: Henry Lum [mailto:[email-masked]]
|Sent: Wednesday, May 11, 2011 11:31 PM
|To: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Leon
Portman; Paul Kyzivat (pkyzivat)
|Cc: [email-masked]
|Subject: RE: [siprec] Does MS have life outside a particular CS? (was
RE:comments on draft-ram-siprec-
|metadata-04)
|
|I also don't see a need to use another unique ID for a media stream as
|the relationship can be inferred by participants and CS.
|
|As for things like MOH, I tend to agree that we need to have an
|automated participant to deliver media as a dialog to a use which is
the
|other participant. Having an explicit relationship for dialogs like
this
|helps us to visualize who the participant is interacting with during
the
|lifetime of the CS (ie. how many times did the participant was put on
|hold?).
|
|On the other hand, if we have a conference mixer that generates a mixed
|media stream to all the conference participants, then do we need a
mixer
|participant that contributes to this mixed output? My initial reaction
|is no, meaning a mixer can be implied in the relationship whenever a
|media stream is sent to multiple participants, but we can also allow
|someone to explicitly model this with a mixer participant.
|
|Regards,
|Henry
|
|> -----Original Message-----
|> From: Muthu ArulMozhi Perumal (mperumal) [mailto:[email-masked]]
|> Sent: Wednesday, May 11, 2011 9:49 AM
|> To: Ram Mohan R (rmohanr); Leon Portman; Paul Kyzivat (pkyzivat);
|Henry
|> Lum
|> Cc: [email-masked]
|> Subject: RE: [siprec] Does MS have life outside a particular CS? (was
|> RE:comments on draft-ram-siprec-metadata-04)
|>
|> If we consider MS as local to a Participant (as John was trying to
|> argue) there seems to be no need for a unique ID for MS since it can
|be
|> inferred from the Participant that can be uniquely identified.
|>
|> The mail thread describes a use-case where multicast MoH played to a
|> number of participants and to the SRC is recorded. Can't the MoH
|source
|> be considered a Participant here?
|>
|> Muthu
|>
|> |-----Original Message-----
|> |From: [email-masked] [mailto:[email-masked]] On
|> Behalf Of Ram Mohan R (rmohanr)
|> |Sent: Wednesday, May 11, 2011 12:52 PM
|> |To: Leon Portman; Paul Kyzivat (pkyzivat); Henry Lum
|> |Cc: [email-masked]
|> |Subject: Re: [siprec] Does MS have life outside a particular CS?
(was
|> RE:comments on draft-ram-siprec-
|> |metadata-04)
|> |
|> |Hello All,
|> |
|> |As per the discussions in last meeting and below mail thread it
|> appears
|> |that we would need global ID to take care of all the cases. However
|> |there is a disagreement with some folks in having a unique ID. I
|would
|> |request people to respond on this mail thread and take this issue to
|> |closure.
|> |
|> |If no one has issues, we will go with globally Unique ID for MS
|block.
|> |
|> |Regards,
|> |Ram
|> |
|> |> -----Original Message-----
|> |> From: [email-masked] [mailto:[email-masked]] On
|> |> Behalf Of Leon Portman
|> |> Sent: Thursday, April 28, 2011 9:28 PM
|> |> To: Paul Kyzivat (pkyzivat); Henry Lum
|> |> Cc: [email-masked]
|> |> Subject: Re: [siprec] Does MS have life outside a particular CS?
|> (was
|> |> RE: comments on draft-ram-siprec-metadata-04)
|> |>
|> |> I agree that we should have all IDs to be globally unique.
|> |>
|> |> Leon
|> |>
|> |> -----Original Message-----
|> |> From: [email-masked] [mailto:[email-masked]] On
|> |> Behalf Of Paul Kyzivat
|> |> Sent: Thursday, April 28, 2011 6:43 PM
|> |> To: Henry Lum
|> |> Cc: [email-masked]
|> |> Subject: Re: [siprec] Does MS have life outside a particular CS?
|> (was
|> |> RE: comments on draft-ram-siprec-metadata-04)
|> |>
|> |>
|> |>
|> |> On 4/28/2011 11:19 AM, Henry Lum wrote:
|> |> > I agree it would be out of scope for two different SRCs to refer
|> to
|> |> > the same CS. The metadata model currently does not seem to
|prevent
|> |> > such scenario, as long as there is a way to identify the same CS
|> |> > across different SRC. The CS Identifier currently states that it
|> is
|> |a
|> |> > unique identifier, and I don't think we should mandate that to
be
|> |> > globally unique across multiple SRCs like the CSG identifier.
|> |>
|> |> Once you decide to have a "unique" id assigned by the SRC, its
very
|> |> little harder to make it globally unique rather than simply unique
|> to
|> |> an RS or an SRC. And there is very little benefit to the SRS to
|> |> narrowing the scope either.
|> |>
|> |> We only get to make this decision once. Its really hard to
retrofit
|> |> later to extend the scope. IMO all of the IDs should be globally
|> |> unique.
|> |> That gives us a lot more flexibility in how this evolves in the
|> |future.
|> |>
|> |> How we convey the id (as a URL, or something else) is another
|> matter,
|> |> and much less of a big deal. If the concern is how many bytes it
|> |> consumes in the message then we can work on that.
|> |>
|> |> In any case, while proposed mechanisms must satisfy the
|> requirements,
|> |> AFAIK there is no reason that a proposed mechanism cannot go
beyond
|> |the
|> |> stated requirements. If there are multiple proposed mechanisms,
and
|> |one
|> |> has ids more global than another, then people can decide which
they
|> |> like better. But the choice is only among what is proposed. So if
|> |there
|> |> are two philosophies in this regard, then maybe there had better
be
|> |two
|> |> proposed mechanisms.
|> |>
|> |> Or, I guess someone could propose a new requirement: "Unique IDs
in
|> |the
|> |> mechanism MUST NOT be globally scoped - they MUST be locally
scoped
|> to
|> |> an RS and duplicated across RSs". (I won't support that one.)
|> |>
|> |>         Thanks,
|> |>         Paul
|> |>
|> |> > Regards,
|> |> > Henry
|> |> >
|> |> >> -----Original Message-----
|> |> >> From: Paul Kyzivat [mailto:[email-masked]]
|> |> >> Sent: Wednesday, April 27, 2011 6:56 PM
|> |> >> To: Henry Lum
|> |> >> Cc: Parthasarathi R (partr); [email-masked]
|> |> >> Subject: Re: [siprec] Does MS have life outside a particular
CS?
|> |> (was
|> |> >> RE: comments on draft-ram-siprec-metadata-04)
|> |> >>
|> |> >>
|> |> >>
|> |> >> On 4/27/2011 5:01 PM, Henry Lum wrote:
|> |> >>>> Presumably the RTP streams associated with the RS end when
the
|> RS
|> |> >>> ends.
|> |> >>>> That does not necessarily mean that the media stream of a CS
|> also
|> |> >> ends
|> |> >>> at
|> |> >>>> that time. It could be picked up again in a different RS by
|the
|> |> > same
|> |> >>> or
|> |> >>>> different SRC.
|> |> >>>
|> |> >>> IIUC, a single CS is only mapped to a single SRC. If we have a
|> |> media
|> |> >>> stream of a CS picked by another SRC, then it should be a
|> |different
|> |> >> CS
|> |> >>> but can be related to the same CS group.
|> |> >>
|> |> >> Two things:
|> |> >>
|> |> >> It could be the same SRC but two different RSs. (Perhaps it
|drops
|> |> the
|> |> >> RS during a long pause, or because the SRS crashed and
restarted
|> |and
|> |> >> the SRC had to reconnect.)
|> |> >>
|> |> >> If there are two different SRCs, and they happen to know it is
|> the
|> |> > same
|> |> >> CS (I'm not proposing *how* they know), it would be better to
|> refer
|> |> >> to the same CS.
|> |> >>
|> |> >> I'm not saying we should require SRCs to do such things - only
|> that
|> |> a
|> |> >> design that permits this is better than one that does not.
|> |> >>
|> |> >>      Thanks,
|> |> >>      Paul
|> |> >>
|> |> >>> Henry
|> |> >>>
|> |> >>>> -----Original Message-----
|> |> >>>> From: [email-masked]
[mailto:[email-masked]]
|> On
|> |> >>> Behalf
|> |> >>>> Of Paul Kyzivat
|> |> >>>> Sent: April-27-11 9:52 AM
|> |> >>>> To: Parthasarathi R (partr)
|> |> >>>> Cc: [email-masked]
|> |> >>>> Subject: Re: [siprec] Does MS have life outside a particular
|> CS?
|> |> >> (was
|> |> >>> RE:
|> |> >>>> comments on draft-ram-siprec-metadata-04)
|> |> >>>>
|> |> >>>> There seems to be some confusion in this discussion about
what
|> a
|> |> MS
|> |> >>> is.
|> |> >>>>
|> |> >>>> On one hand there is an m-line in the SDP of the RS, and a
|> |> >>> corresponding RTP
|> |> >>>> stream.
|> |> >>>>
|> |> >>>> On another hand there is an m-line in a CS and a
corresponding
|> |RTP
|> |> >>> stream.
|> |> >>>>
|> |> >>>> And then there is an MS described in the metadata conveyed
|over
|> |> the
|> |> >>> RS.
|> |> >>>>
|> |> >>>> And for both of the above, a single m-line might correspond
to
|> |> >>> different RTP
|> |> >>>> streams over time, due to renegotiating the address and/or
|port
|> |of
|> |> >> the
|> |> >>>> recipient, or by a different sender sending to the same port.
|> |> >>>>
|> |> >>>> There is a mapping between one or more RTP streams in the CS
|> (or
|> |> >>> multiple
|> |> >>>> CSs?) and one or more RTP streams in the RS. The metadata
|> |> hopefully
|> |> >>>> describes that mapping.
|> |> >>>>
|> |> >>>> But perhaps we don't have full agreement on what sorts of
|> |mappings
|> |> >> are
|> |> >>>> possible. Some that I think we allow are:
|> |> >>>> - one CS RTP stream to one RS RTP stream.
|> |> >>>> - multiple concurrent CS RTP streams mixed to one
|> |> >>>>      RS RTP stream
|> |> >>>> - multiple CS RTP streams sequentially mapped to the same
|> |> >>>>      RS RTP stream
|> |> >>>> ...
|> |> >>>>
|> |> >>>> Presumably the RTP streams associated with the RS end when
the
|> RS
|> |> >>> ends.
|> |> >>>> That does not necessarily mean that the media stream of a CS
|> also
|> |> >> ends
|> |> >>> at
|> |> >>>> that time. It could be picked up again in a different RS by
|the
|> |> > same
|> |> >>> or
|> |> >>>> different SRC.
|> |> >>>>
|> |> >>>>    Thanks,
|> |> >>>>    Paul
|> |> >>>>
|> |> >>>> On 4/27/2011 2:30 AM, Parthasarathi R (partr) wrote:
|> |> >>>>> John,
|> |> >>>>>
|> |> >>>>> My intention is show the complexity in the metadata model in
|> the
|> |> >>>>> current form. Global unique id solves the issue but let us
|> |> explore
|> |> >>> for
|> |> >>>>> better optimized solution with more local unique id if any
|> |> exists.
|> |> >>>>>
|> |> >>>>> I have created another mail thread for adding the recording
|> type
|> |> >>>>> attribute which helps in most of the metadata blocks to have
|> |> local
|> |> >>>>> unique id rather than global unique id. Let us see how
others
|> |> >>>>> visualize that attribute.
|> |> >>>>>
|> |> >>>>> IMO, it may better to have globally unique id with the
|current
|> |> >>>>> metadata model attributes. We may be able to add the
|normative
|> |> >>>>> statement that "Media stream (MS) MUST be terminated when CS
|> is
|> |> >>>>> terminated" in the metadata but in reality, MS is within the
|> |> scope
|> |> >>> of
|> |> >>>>> RS which is forced to delete for no reason. These sort will
|be
|> |> >>>>> restrictive for few SRC implementation. For eg: RS may
|created
|> |MS
|> |> >>> with
|> |> >>>>> RSVP which may not prefer to terminate the resource during
RS
|> |> >>>>> mid-session changes like CS changes even though intermediate
|> |time
|> |> >>> with
|> |> >>>>> no media but the above normative statement forces to break
|> those
|> |> >> SRC
|> |> >>>> implementation.
|> |> >>>>>
|> |> >>>>> Please read inline for more comments.
|> |> >>>>>
|> |> >>>>> Thanks
|> |> >>>>> Partha
|> |> >>>>>
|> |> >>>>> -----Original Message-----
|> |> >>>>> From: Elwell, John
|[mailto:[email-masked]]
|> |> >>>>> Sent: Friday, April 22, 2011 1:48 AM
|> |> >>>>> To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul
|> Kyzivat
|> |> >>>>> (pkyzivat)
|> |> >>>>> Cc: [email-masked]
|> |> >>>>> Subject: RE: Does MS have life outside a particular CS? (was
|> RE:
|> |> >>>>> [siprec] comments on draft-ram-siprec-metadata-04)
|> |> >>>>>
|> |> >>>>>
|> |> >>>>>
|> |> >>>>>> -----Original Message-----
|> |> >>>>>> From: Parthasarathi R (partr) [mailto:[email-masked]]
|> |> >>>>>> Sent: 21 April 2011 17:20
|> |> >>>>>> To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat
|> |(pkyzivat)
|> |> >>>>>> Cc: [email-masked]
|> |> >>>>>> Subject: RE: Does MS have life outside a particular CS?
(was
|> |> >>>>>> RE: [siprec] comments on draft-ram-siprec-metadata-04)
|> |> >>>>>>
|> |> >>>>>> John,
|> |> >>>>>>
|> |> >>>>>> Please read inline.
|> |> >>>>>>
|> |> >>>>>> Thanks
|> |> >>>>>> Partha
|> |> >>>>>>
|> |> >>>>>> -----Original Message-----
|> |> >>>>>> From: Elwell, John [mailto:john.elwell@siemens-
|> enterprise.com]
|> |> >>>>>> Sent: Thursday, April 21, 2011 9:12 PM
|> |> >>>>>> To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul
|> |Kyzivat
|> |> >>>>>> (pkyzivat)
|> |> >>>>>> Cc: [email-masked]
|> |> >>>>>> Subject: RE: Does MS have life outside a particular CS?
(was
|> |RE:
|> |> >>>>>> [siprec] comments on draft-ram-siprec-metadata-04)
|> |> >>>>>>
|> |> >>>>>> Partha,
|> |> >>>>>>
|> |> >>>>>>> -----Original Message-----
|> |> >>>>>>> From: Parthasarathi R (partr) [mailto:[email-masked]]
|> |> >>>>>>> Sent: 21 April 2011 14:25
|> |> >>>>>>> To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat
|> |> (pkyzivat)
|> |> >>>>>>> Cc: [email-masked]
|> |> >>>>>>> Subject: RE: Does MS have life outside a particular CS?
|(was
|> |> >>>>>>> RE: [siprec] comments on draft-ram-siprec-metadata-04)
|> |> >>>>>>>
|> |> >>>>>>> John,
|> |> >>>>>>>
|> |> >>>>>>> I could think of one usecase wherein MS is outside CS but
|> |> within
|> |> >>>>>>> single RS.  The usecase is multiple CS within single RS
and
|> |MS.
|> |> >>> The
|> |> >>>>>>> usecase is as follows:
|> |> >>>>>>>
|> |> >>>>>>> B2BUA acts as SRC. A, B, C are participants within single
|> |> B2BUA.
|> |> >> A
|> |> >>>>>>> creates single RS for a CSG.
|> |> >>>>>>>
|> |> >>>>>>> 1) A calls B through B2BUA. B2BUA creates RS towards SRS
|> with
|> |> >>> CSG1,
|> |> >>>>>>> CS1,
|> |> >>>>>>> MS1 (A's media stream), MS2 (B's media stream),
|Participant1
|> |as
|> |> >> A&
|> |> >>>>>>> Participant2 as B.
|> |> >>>>>> [JRE] Why two media streams? Why not a single MS, with both
|A
|> |> and
|> |> >> B
|> |> >>>>>> sending and receiving that MS?
|> |> >>>>>> <Partha>    The media streams are un-mixed, MS1 points to
|RTP
|> |> from
|> |> >> A
|> |> >>>>>> through label attribute in MS1 SDP, MS2 points to RTP from
B
|> |> >>> through
|> |> >>>>>> label attribute in MS2 SDP</Partha>
|> |> >>>>> [JRE] Reading the metadata model again, I think it does seem
|> to
|> |> >>> imply
|> |> >>>>> two Media Stream objects if the two directions for a 2-party
|> |call
|> |> >>> are
|> |> >>>>> sent unmixed (as two m-lines in the RS SDP), so I will
|concede
|> |> > that
|> |> >>> we
|> |> >>>>> have two Media Stream objects here. I had been thinking of a
|> |> >>> slightly
|> |> >>>>> different model, where there is one Media Stream, but
|> |> associations
|> |> >>>>> between the Media Stream and Participants pointed to
|different
|> |> >>> m-lines
|> |> >>>>> in the RS SDP.
|> |> >>>>>
|> |> >>>>>>
|> |> >>>>>>> 2) B connects with C through B2BUA
|> |> >>>>>>> 3) B transfer the call of A&    B to C using REFER, B2BUA
|> |> >>>>>> converts REFER
|> |> >>>>>>
|> |> >>>>>>> to RE-INVITE towards A&    C and A&    C are connected.
|> B2BUA
|> |> >>>>>> updates RS
|> |> >>>>>>> with CS2, Participant1 as A&    participant2 as C, MS1(A's
|> |> media
|> |> >>>>>>> stream), MS2(C's media stream).
|> |> >>>>>> [JRE] I would have expected, from my understanding of the
|> |> > metadata
|> |> >>>>>> model, that the CS2 would have a new MS, with both A and B
|> |> > sending
|> |> >>>>>> and
|> |> >>>>>
|> |> >>>>>> receiving that new MS.
|> |> >>>>>>
|> |> >>>>>> <Partha>    It is not mandatory because participant
|> information
|> |> >> will
|> |> >>> be
|> |> >>>>>> updated and pointing to the same m-line in RS with same
|label
|> |> >>>>>> attribute.
|> |> >>>>>>    From SRS perspective, the same media stream with the
|> update
|> |> in
|> |> >> the
|> |> >>>>>> participant name only. Say MS2 is stored as one record with
|B
|> |as
|> |> >>>>>> participant for T0 to T1 timelines and C as participant
from
|> T1
|> |> > to
|> |> >>> T2.
|> |> >>>>>> </Partha>
|> |> >>>>> [JRE] Or alternatively it could be modelled that when a new
|CS
|> |> >>> starts
|> |> >>>>> there is a new Media Stream object, still pointing to the
|same
|> |> >>> m-line
|> |> >>>>> in the RS SDP.
|> |> >>>>>
|> |> >>>>> <Partha>    The purpose of unique-id will go for toss here.
|> The
|> |> > same
|> |> >>>>> media stream (MS) has unique id "id1" initially and later it
|> |will
|> |> >>> have "id2"
|> |> >>>>> which will not be good for replay. Of course, MS life is
|> always
|> |> >>> within
|> |> >>>>> RS in this scenario but not within CS. So, Unique Id within
|RS
|> |> > will
|> |> >>>>> serve the purpose</Partha>
|> |> >>>>>
|> |> >>>>>     This would avoid the need for a Media Stream object to
|> |> survive
|> |> >>>>> beyond the lifetime of a CS, and therefore allow local
|> |> >>> identification.
|> |> >>>>> While there is no CS in progress, the m-line would be
|disabled
|> |> >> (port
|> |> >>>>> 0) and would not be referenced by any Media Stream.
|> |> >>>>>
|> |> >>>>> <Partha>    RS m-line is not required to 0 because it shall
|> |> change
|> |> >>> into
|> |> >>>>> "a=inactive" as well. There is no change in the resource
|> |> >> reservation
|> |> >>>>> in both SRC and SRS</Partha>
|> |> >>>>>
|> |> >>>>>>
|> |> >>>>>>> There is no update on RS1, CSG1, MS1, MS2. MS2 will become
|> MS2
|> |> >>> with
|> |> >>>>>>> the new association and in terms of format, it will
|> associate
|> |> >> with
|> |> >>>>>>> <send>    tag.
|> |> >>>>>>>
|> |> >>>>>>> In the above scenario, MS have life outside CS but it is
|> |within
|> |> >>> RS.
|> |> >>>>>> [JRE] I can see how it COULD work like that, but it is not
|> |> >>> intuitive.
|> |> >>>>>>
|> |> >>>>>> <Partha>    In SIPREC solution, UPDATE message with
|> CS2(session
|> |> >>>>>> element) ,
|> |> >>>>>> participant "C" element are received in SRS. This partial
|> |update
|> |> >> of
|> |> >>>>>> UPDATE helps to make this scenario work. There is no change
|> in
|> |> >> term
|> |> >>>>>> stream element or RS SDP</Partha>
|> |> >>>>>>
|> |> >>>>>> To me, a new CS means the existing media stream stops and a
|> new
|> |> >>> media
|> |> >>>>>> stream is created.
|> |> >>>>>>
|> |> >>>>>> <Partha>    I'm interested knowing whether you propose that
|> MS
|> |> > MUST
|> |> >>>>>> stop in case CS ends and the above scenario is outside the
|> |scope
|> |> >> of
|> |> >>>> SIPREC?
|> |> >>>>>> </Partha>
|> |> >>>>>>
|> |> >>>>>>> The
|> |> >>>>>>> unique id shall be within RS scope as mentioned in IETF-80
|> |> >>> meeting.
|> |> >>>>>>> But in another situation, MS is outside the scope of RS
but
|> |> >>>>>> within CS
|> |> >>>>>>> and the usecase is Multiple RS for single CS, details are
|> |> >>>>>> as follows:
|> |> >>>>>>>
|> |> >>>>>>> A, B are pariticipants. A acts as SRC which tear down RS
|> |> >>>>>> whenever hold
|> |> >>>>>>
|> |> >>>>>>> happens&    creates new RS when resume happens.
|> |> >>>>>>>
|> |> >>>>>>> 1) A calls B. A creates RS1 towards SRS with CS1, MS1 (A's
|> |> media
|> |> >>>>>>> stream), MS2 (B's Media stream),Participant1 as A&
|> |> >>>>>> Participant2 as B.
|> |> >>>>>> [JRE] Again, I would model this as a single MS, to which
|both
|> A
|> |> >> and
|> |> >>> B
|> |> >>>>>> contribute.
|> |> >>>>>> <Partha>    Again, unmixed stream from A and B</Partha>
|> |> >>>>>>> 2) A put B on hold. A tear down RS1.
|> |> >>>>>>> 3) A resume B. A creates RS2 towards SRS with CS1, MS1
(A's
|> |> > media
|> |> >>>>>>> stream), MS2 (B's Media stream),Participant1 as A&
|> |> >>>>>> Participant2 as B
|> |> >>>>>>>
|> |> >>>>>>> Here MS1&    MS2 needs to be same across RS to group media
|> |> > streams
|> |> >>>>>>> correctly. Please let me know your opinion here.
|> |> >>>>>>
|> |> >>>>>> [JRE] Although I disagree that we have two Media Streams
|> here,
|> |I
|> |> >> do
|> |> >>>>>> agree that the single Media Stream could be considered to
|> |> survive
|> |> >>> the
|> |> >>>>>> hold/resume, and hence survive from RS1 to RS2. But the MS
|is
|> |> >>> within
|> |> >>>>>> the context of the same CS (CS1), and therefore this is
|> outside
|> |> >> the
|> |> >>>>>> scope of this particular thread, which is asking whether an
|> MS
|> |> > can
|> |> >>>>>> have a life outside a particular CS. In this case the MS
|> |> > continues
|> |> >>> to
|> |> >>>>>> be associated with the CS, so I don't have a problem with
|> that.
|> |> >>>>>>
|> |> >>>>>> <Partha>    I have 2nd example to illustrate MS have life
|> |> outside
|> |> >> RS.
|> |> >>>>>> </Partha>
|> |> >>>>>>
|> |> >>>>>> So you have failed to convince me that an MS needs to have
a
|> |> life
|> |> >>>>>> outside a CS.
|> |> >>>>>>
|> |> >>>>>> <Partha>    In case the above scenario-1 way of recording
is
|> |> >> outside
|> |> >>>>>> the scope of SIPREC, I agree with you that MS does not have
|> |life
|> |> >>>>>> outside a
|> |> >>>>>
|> |> >>>>>> particular CS</Partha>
|> |> >>>>> [JRE] I assume you are talking about the call transfer case.
|I
|> |am
|> |> >>> not
|> |> >>>>> saying that use case is outside the scope of SIPREC. I am
|just
|> |> >>> saying
|> |> >>>>> that it can be modelled a different way, which may be
|> |> advantageous
|> |> >>> in
|> |> >>>>> terms of the number of globally unique identifiers needed.
|> |> >>>>>
|> |> >>>>>
|> |> >>>>> John (as individual)
|> |> >>>>>
|> |> >>>>>
|> |> >>>>>
|> |> >>>>>>
|> |> >>>>>> John (as individual)
|> |> >>>>>>
|> |> >>>>>>
|> |> >>>>>>>
|> |> >>>>>>> Having said that MS have life outside a particular CS, I
|> |create
|> |> >>>>>>> separate thread within unique how it shall be handled.
|> |> >>>>>>>
|> |> >>>>>>> Thanks
|> |> >>>>>>> Partha
|> |> >>>>>>>
|> |> >>>>>>> -----Original Message-----
|> |> >>>>>>> From: Elwell, John
|> [mailto:[email-masked]]
|> |> >>>>>>> Sent: Thursday, April 21, 2011 12:01 PM
|> |> >>>>>>> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
|> |> >>>>>>> Cc: Parthasarathi R (partr); [email-masked]
|> |> >>>>>>> Subject: Does MS have life outside a particular CS? (was
|> |> >>>>>> RE: [siprec]
|> |> >>>>>>> comments on draft-ram-siprec-metadata-04)
|> |> >>>>>>>
|> |> >>>>>>>
|> |> >>>>>>>
|> |> >>>>>>>> -----Original Message-----
|> |> >>>>>>>> From: Ram Mohan R (rmohanr) [mailto:[email-masked]]
|> |> >>>>>>>> Sent: 20 April 2011 18:08
|> |> >>>>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat)
|> |> >>>>>>>> Cc: Parthasarathi R (partr); [email-masked]
|> |> >>>>>>>> Subject: RE: [siprec] comments on
|> |draft-ram-siprec-metadata-04
|> |> >>>>>>>>
|> |> >>>>>>>> Hi John,
|> |> >>>>>>>>
|> |> >>>>>>>> Please see inline [RAM]
|> |> >>>>>>>>
|> |> >>>>>>>>> -----Original Message-----
|> |> >>>>>>>>> From: Elwell, John [mailto:john.elwell@siemens-
|> |> enterprise.com]
|> |> >>>>>>>>> Sent: Wednesday, April 20, 2011 8:19 PM
|> |> >>>>>>>>> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
|> |> >>>>>>>>> Cc: Parthasarathi R (partr); [email-masked]
|> |> >>>>>>>>> Subject: RE: [siprec] comments on
|> draft-ram-siprec-metadata-
|> |> 04
|> |> >>>>>>>>>
|> |> >>>>>>>>>
|> |> >>>>>>>>>
|> |> >>>>>>>>>> -----Original Message-----
|> |> >>>>>>>>>> From: Ram Mohan R (rmohanr) [mailto:[email-masked]]
|> |> >>>>>>>>>> Sent: 20 April 2011 14:52
|> |> >>>>>>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat)
|> |> >>>>>>>>>> Cc: Parthasarathi R (partr); [email-masked]
|> |> >>>>>>>>>> Subject: RE: [siprec] comments on
|> |> > draft-ram-siprec-metadata-04
|> |> >>>>>>>>>>
|> |> >>>>>>>>>> John,
|> |> >>>>>>>>>>
|> |> >>>>>>>>>> I agree with you that normal cases RS will remain at
|> |> >>>>>>> least for the
|> |> >>>>>>>
|> |> >>>>>>>>>> duration of CS. However it is common to have use cases
|> |where
|> |> >>>>>>>>> recording
|> |> >>>>>>>>>> is done for first few mins of a CS and then stopped,
|> |> >>>>>>>> re-started at a
|> |> >>>>>>>>>> later point (e.g Recording of a company meeting where
|> |> >>>>>>> you may want
|> |> >>>>>>>> to
|> |> >>>>>>>>>> record only portions of meeting).
|> |> >>>>>>>>>>
|> |> >>>>>>>>>> In any case, the point I like to high light here is, MS
|> |> >>>>>>>> block could
|> |> >>>>>>>>> be
|> |> >>>>>>>>>> common across RS and even across CS[ due to consult
|> |> >>>>>>>> transfer e.t.c].
|> |> >>>>>>>>>> These use cases indicate the need to have a unique ID
|> |> >>>>>>> for MS block
|> |> >>>>>>>
|> |> >>>>>>>>>> (similar to the UUID that we have defined in format) as
|> |> >>>>>>> we cannot
|> |> >>>>>>>>>> depend on neither CS ID or RS ID.
|> |> >>>>>>>>> [JRE] I am having a hard time understanding the concept
|> |> >>>>>>> of a single
|> |> >>>>>>>>> Media Stream that survives across multiple CSs. For
|> |> >>>>>>> example, in the
|> |> >>>>>>>>> case of transfer, I would have thought new Media
|> |> >>>>>> Streams would be
|> |> >>>>>>>>> created.
|> |> >>>>>>>>
|> |> >>>>>>>> [RAM]
|> |> >>>>>>>> Here is my thoughts.
|> |> >>>>>>>> 1) There can be multiple RS per CS
|> |> >>>>>>>> RS1 --- CS1--MS1
|> |> >>>>>>>> RS2----CS1--MS1
|> |> >>>>>>>> Examples are partial recording of CS (like recording
parts
|> |> >>>>>>> of meeting,
|> |> >>>>>>>
|> |> >>>>>>>> redundant recording where there are multiple SRCs
|recording
|> |> >>>>>>> the same
|> |> >>>>>>>> CS)
|> |> >>>>>>> [JRE] Agreed. In this case MS1 is local to CS1.
|> |> >>>>>>>
|> |> >>>>>>>>
|> |> >>>>>>>> 2) There can be same Media Stream across multiple CS.
|> |> >>>>>>>> RS1--- CS1--- MS1
|> |> >>>>>>>> RS2--CS2--MS1
|> |> >>>>>>>> Examples are Multicast MoH played to multiple end points
|> who
|> |> > are
|> |> >>>>>>>> potentially part of disjoint CSs where each CS is
recorded
|> |> >>>>>>> as part of
|> |> >>>>>>>> separate RS.
|> |> >>>>>>>>
|> |> >>>>>>>> Of course the above is arguable where the stream is same
|or
|> |> >>>>>>> different.
|> |> >>>>>>>> My view is since the UA (that supplies the Multicast MoH)
|> and
|> |> >> its
|> |> >>>>>>>> media are same across all CS, I think it can be
|represented
|> |> >>>>>>> as same MS
|> |> >>>>>>>
|> |> >>>>>>>> block.
|> |> >>>>>>> [JRE] I would argue these are different MSs. I agree that
a
|> |> >> medium
|> |> >>>>>>> such as music on hold might be sent, in synch, to multiple
|> |> >>>>>>> participants in multiple CSs. In that particular situation
|> |> >>>>>> there might
|> |> >>>>>>
|> |> >>>>>>> be some efficiency saving by calling it the same MS.
|> |> >>>>>> However, I would
|> |> >>>>>>> suggest (although this is not my field of expertise) it
|> would
|> |> >> make
|> |> >>>>>>> life a lot harder for the SRS and its database. I would
|> |> >>>>>> have expected
|> |> >>>>>>> to want to record a complete CS (all its participants and
|> |media
|> |> >>>>>>> streams)  as a complete recording, which could be deleted,
|> |> >>>>>> copied, and
|> |> >>>>>>
|> |> >>>>>>> so on without having to go looking for other objects that
|> |> >> complete
|> |> >>>>>>> that recording and are shared with other recordings. For
|> |> >>>>>> example, if
|> |> >>>>>>> you delete a recording, you would want to delete all its
|> |> >>>>>> MSs, but not
|> |> >>>>>>> those used by other recordings, although you would need a
|> |> > garbage
|> |> >>>>>>> collection mechanism to delete an MS recording when it is
|no
|> |> >>> longer
|> |> >>>>>>> used by any CS recordings. Rather ugly. Making a MS local
|to
|> a
|> |> > CS
|> |> >>>>>>> would simplify all this.
|> |> >>>>>>>
|> |> >>>>>>>>
|> |> >>>>>>>>
|> |> >>>>>>>> However it is still possible to treat each as separate
|> |> >>>>>>> stream in the
|> |> >>>>>>>> model, in which case the information that it is the same
|MS
|> |> >>>>>>> played by
|> |> >>>>>>>> a UA to different CS will be lost. I don't know if there
|is
|> |an
|> |> >>>>>>>> interest to capture this level of detail and if it is of
|> |> >>>>>> any use to
|> |> >>>>>>>> SRS.
|> |> >>>>>>> [JRE] I assume what you are saying here is not that
|> |> >>>>>> information will
|> |> >>>>>>> be lost, but that you will be unable to tell, without
doing
|> a
|> |> >>>>>>> comparison, whether two different MSs played to
|participants
|> |in
|> |> >>> two
|> |> >>>>>>> different CSs are identical or not for the particular time
|> |> >>>>>> span that
|> |> >>>>>>> is common. I don't see where such a requirement would come
|> |> from.
|> |> >>>>>>>
|> |> >>>>>>> John (as individual)
|> |> >>>>>>>
|> |> >>>>>>>
|> |> >>>>>>
|> |> >>>>>
|> |> >>>> _______________________________________________
|> |> >>>> siprec mailing list
|> |> >>>> [email-masked]
|> |> >>>> https://www.ietf.org/mailman/listinfo/siprec
|> |> >>>
|> |> >>>
|> |> >>>
|> |> >
|>
|---------------------------------------------------------------------
|> |> >> ----------------------------------------------
|> |> >>> CONFIDENTIALITY NOTICE: This e-mail and any files attached may
|> |> >> contain confidential and proprietary information of Alcatel-
|> Lucent
|> |> >> and/or its affiliated entities. Access by the intended
recipient
|> |> only
|> |> >> is authorized. Any liability arising from any party acting, or
|> |> >> refraining from acting, on any information contained in this
|> e-mail
|> |> >> is hereby excluded. If you are not the intended recipient,
|please
|> |> >> notify the sender immediately, destroy the original
transmission
|> |and
|> |> >> its attachments and do not disclose the contents to any other
|> |> person,
|> |> >> use it for any purpose, or store or copy the information in any
|> |> medium.
|> |> >> Copyright in this e-mail and any attachments belongs to
|> |> >> Alcatel-Lucent and/or its affiliated entities.
|> |> >>>
|> |> >>>
|> |> >
|> |> >
|> |> >
|>
|---------------------------------------------------------------------
|> |> -
|> |> > ---------------------------------------------
|> |> > CONFIDENTIALITY NOTICE: This e-mail and any files attached may
|> |> contain confidential and proprietary information of Alcatel-Lucent
|> |> and/or its affiliated entities. Access by the intended recipient
|> only
|> |> is authorized. Any liability arising from any party acting, or
|> |> refraining from acting, on any information contained in this
e-mail
|> is
|> |> hereby excluded. If you are not the intended recipient, please
|> notify
|> |> the sender immediately, destroy the original transmission and its
|> |> attachments and do not disclose the contents to any other person,
|> use
|> |> it for any purpose, or store or copy the information in any
medium.
|> |> Copyright in this e-mail and any attachments belongs to
|> Alcatel-Lucent
|> |> and/or its affiliated entities.
|> |> >
|> |> >
|> |> _______________________________________________
|> |> siprec mailing list
|> |> [email-masked]
|> |> https://www.ietf.org/mailman/listinfo/siprec
|> |> _______________________________________________
|> |> siprec mailing list
|> |> [email-masked]
|> |> https://www.ietf.org/mailman/listinfo/siprec
|> |_______________________________________________
|> |siprec mailing list
|> [email-masked]
|> |https://www.ietf.org/mailman/listinfo/siprec
|
|
|-----------------------------------------------------------------------
-------------------------------
|-------------
|CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain
confidential and proprietary
|information of Alcatel-Lucent and/or its affiliated entities. Access by
the intended recipient only is
|authorized. Any liability arising from any party acting, or refraining
from acting, on any information
|contained in this e-mail is hereby excluded. If you are not the
intended recipient, please notify the
|sender immediately, destroy the original transmission and its
attachments and do not disclose the
|contents to any other person, use it for any purpose, or store or copy
the information in any medium.
|Copyright in this e-mail and any attachments belongs to Alcatel-Lucent
and/or its affiliated entities.
|

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 12 May 2011 09:28:18 +0200

I don't recall arguing that MS should be local to a Participant. In
http://www.ietf.org/mail-archive/web/siprec/current/msg01888.html
I argued MS should be local to a CS. My reasoning is as follows.

Consider a conference call that has 3 media streams - audio, main video and presentation video. Those streams will remain in existence throughout the call, but participants will come and go. For example, the conference could start with participants A, B and C. Then D and E could join, then A could leave, and so on, so you could even end up with just D, E and F in the call at the end, but they could still be using those three media streams - audio, main video and presentation video. So there is no single Participant that a media stream can be anchored to for the entire call - the stream instead has to be anchored to the CS. Also, the presentation stream can have a number of different Participants transmitting to it, but only one at a time, governed by floor control.

So I had argued that an MS should be local to a Participant. At that time, I had assumed an MS was modelling a media stream on the CS, but the thread then went in the direction of pointing out that really it models a media stream on the RS. For example, the audio stream in the above example might be sent mixed (contributions from all participants) using a single m-line in the RS, or might be sent unmixed using multiple m-lines in the RS. Some people were arguing that in the first case this would be modelled as one MS and in the second case it would be modelled as multiple MSs. I am not sure we really resolved that (personally I was more comfortable with modelling an MS as relating to a CS media stream.

Anyway, however MS is modelled, it doesn't seem feasible to make it local to a Participant, but it may be feasible to make it local to a CS.

But a further issue was raised on the thread. If I use the same RS m-line to represent a medium from a number of CSs in series, is this the same MS or are they different MSs? If they are the same MS, it means the MS object does have a life outside a CS. But then I would argue it only needs an ID local to the RS. If the RS object is uniquely identified by the SIP dialog identifier, the MS object would be sufficiently identified by the SDP m-line on that dialog.

So I am afraid that before we can resolve the question of unique or local MS identifiers, we first need to clarify what the MS object is and what its lifetime is.

John (as individual)

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Muthu ArulMozhi
> Perumal (mperumal)
> Sent: 11 May 2011 14:49
> To: Ram Mohan R (rmohanr); Leon Portman; Paul Kyzivat
> (pkyzivat); Henry Lum
> Cc: [email-masked]
> Subject: Re: [siprec] Does MS have life outside a particular
> CS? (was RE:comments on draft-ram-siprec-metadata-04)
>
> |> >>>>>> From: Elwell, John

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 18 May 2011 23:18:50 +0530

John,

Your below mail is a good summary for the decision happened so far. MS
lifetime depends upon the relation between RS & CS in a given
deployment. My understanding w.r.t RS & CS relationship for MS lifetime
is as follows:

One RS - One CS: MS lifetime is within the scope of single RS or single
CS 

One RS - Many CS: MS lifetime is within the scope of single RS 

Many RS - One CS: MS lifetime is within the scope of single CS

Many RS - Many CS: MS lifetime is within the scope of Multiple RS or
Multiple CS. 

As Many RS- Many CS mechanism is adopted, there is a need for global
unique id for MS.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Elwell, John
Sent: Thursday, May 12, 2011 12:58 PM
To: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Leon
Portman; Paul Kyzivat (pkyzivat); Henry Lum
Cc: [email-masked]
Subject: Re: [siprec] Does MS have life outside a particular CS?(was
RE:comments on draft-ram-siprec-metadata-04)

Consider a conference call that has 3 media streams - audio, main video
and presentation video. Those streams will remain in existence
throughout the call, but participants will come and go. For example, the
conference could start with participants A, B and C. Then D and E could
join, then A could leave, and so on, so you could even end up with just
D, E and F in the call at the end, but they could still be using those
three media streams - audio, main video and presentation video. So there
is no single Participant that a media stream can be anchored to for the
entire call - the stream instead has to be anchored to the CS. Also, the
presentation stream can have a number of different Participants
transmitting to it, but only one at a time, governed by floor control.

So I had argued that an MS should be local to a Participant. At that
time, I had assumed an MS was modelling a media stream on the CS, but
the thread then went in the direction of pointing out that really it
models a media stream on the RS. For example, the audio stream in the
above example might be sent mixed (contributions from all participants)
using a single m-line in the RS, or might be sent unmixed using multiple
m-lines in the RS. Some people were arguing that in the first case this
would be modelled as one MS and in the second case it would be modelled
as multiple MSs. I am not sure we really resolved that (personally I was
more comfortable with modelling an MS as relating to a CS media stream.

Anyway, however MS is modelled, it doesn't seem feasible to make it
local to a Participant, but it may be feasible to make it local to a CS.

But a further issue was raised on the thread. If I use the same RS
m-line to represent a medium from a number of CSs in series, is this the
same MS or are they different MSs? If they are the same MS, it means the
MS object does have a life outside a CS. But then I would argue it only
needs an ID local to the RS. If the RS object is uniquely identified by
the SIP dialog identifier, the MS object would be sufficiently
identified by the SDP m-line on that dialog.

So I am afraid that before we can resolve the question of unique or
local MS identifiers, we first need to clarify what the MS object is and
what its lifetime is.

John (as individual)

> [mailto:[email-masked]] On Behalf Of Muthu ArulMozhi Perumal 
> (mperumal)
> Sent: 11 May 2011 14:49
> Henry Lum
> argue) there seems to be no need for a unique ID for MS since it can 
> be inferred from the Participant that can be uniquely identified.
>
> number of participants and to the SRC is recorded. Can't the MoH 
> source be considered a Participant here?
>
> Muthu
>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 18 May 2011 20:54:30 +0200

> Sent: 18 May 2011 18:49
> To: Elwell, John; Muthu Arul Mozhi Perumal (mperumal); Ram
> Mohan R (rmohanr); Leon Portman; Paul Kyzivat (pkyzivat); Henry Lum
> Cc: [email-masked]
> Subject: RE: [siprec] Does MS have life outside a particular
> CS?(was RE:comments on draft-ram-siprec-metadata-04)
>
> John,
>
[JRE] I don't follow your reasoning with the above two bullets. I think this gives MS an inconsistent meaning, in that an MS sometimes maps to one RS and multiple CS, and in other situations an MS maps to one CS and multiple RSs. I would have great difficulty understanding what a MS really is. Up to now we have discussed a MS having a lifetime only in the context of a CS and at other times we have discussed a MS having a lifetime only in the context of an RS (in this case a 1:1 mapping to an m-line in the SDP).

> Many RS - Many CS: MS lifetime is within the scope of Multiple RS or
[JRE] In this case, what is the defining character of an MS, making it the same MS even though it spans many CSs and many RSs? I can't really grasp the concept.

John (as individual)

> [mailto:[email-masked]] On Behalf
> Of Elwell, John

---

From: Leon Portman <[email-masked]>
Date: Thu, 19 May 2011 20:01:09 +0300

I agree with John. From my point of view MS represent CS media, And it can be mapped to zero or more RS m-line via metadata labels.

Leon

-----Original Message-----
From: Elwell, John [mailto:[email-masked]]
Sent: Wednesday, May 18, 2011 9:55 PM
To: Parthasarathi R (partr); Muthu Arul Mozhi Perumal (mperumal); Ram Mohan R (rmohanr); Leon Portman; Paul Kyzivat (pkyzivat); Henry Lum
Cc: [email-masked]
Subject: RE: [siprec] Does MS have life outside a particular CS?(was RE:comments on draft-ram-siprec-metadata-04)

> To: Elwell, John; Muthu Arul Mozhi Perumal (mperumal); Ram Mohan R
> (rmohanr); Leon Portman; Paul Kyzivat (pkyzivat); Henry Lum
> Cc: [email-masked]
> Subject: RE: [siprec] Does MS have life outside a particular CS?(was
> deployment. My understanding w.r.t RS & CS relationship for MS
> lifetime is as follows:
>
> One RS - One CS: MS lifetime is within the scope of single RS or
> single CS
>

John (as individual)

> [mailto:[email-masked]] On Behalf Of Elwell, John
> Consider a conference call that has 3 media streams - audio, main
> video and presentation video. Those streams will remain in existence
> throughout the call, but participants will come and go. For example,
> the conference could start with participants A, B and C. Then D and E
> could join, then A could leave, and so on, so you could even end up
> with just D, E and F in the call at the end, but they could still be
> using those three media streams - audio, main video and presentation
> video. So there is no single Participant that a media stream can be
> anchored to for the entire call - the stream instead has to be
> anchored to the CS. Also, the presentation stream can have a number of
> different Participants transmitting to it, but only one at a time,
> governed by floor control.
>
> using a single m-line in the RS, or might be sent unmixed using
> multiple m-lines in the RS. Some people were arguing that in the first
> case this would be modelled as one MS and in the second case it would
> be modelled as multiple MSs. I am not sure we really resolved that
> (personally I was more comfortable with modelling an MS as relating to
> a CS media stream.
>
> m-line to represent a medium from a number of CSs in series, is this
> the same MS or are they different MSs? If they are the same MS, it
> means the MS object does have a life outside a CS. But then I would
> argue it only needs an ID local to the RS. If the RS object is
> uniquely identified by the SIP dialog identifier, the MS object would
> be sufficiently identified by the SDP m-line on that dialog.
>
> local MS identifiers, we first need to clarify what the MS object is
> and what its lifetime is.
>
> John (as individual)
>
>

---

From: "Henry Lum" <[email-masked]>
Date: Thu, 19 May 2011 11:39:25 -0700

I agree with John that a recording session transports recorded streams
and are already described in the SIP session so there is no need to
model recorded streams in the metadata model. MS in the metadata model,
on the other hand, explains a media stream that is part a CS, and the
recorded streams in the RS just refer to which MS in the model is
actually being recorded. When we record unmixed streams as a single
m-line in the RS, I think we should model as multiple MS in the metadata
model but all the MS would refer to the same label in the recorded
stream. 

When we relate a MS directly to a CS, I think it implicitly means that a
CS owns some sort of media sources that generates media. In other words,
CS owns some automated participants as media sources but we don't
explicitly model them. I am okay with this definition since the SRC can
choose to model this either way - meaning if there is need to show what
the CS is doing to the media sources then the SRC can model a
participant that generates the media to explain what it is. These
implicit participants should terminate whenever the MS terminates or the
CS terminates.

Henry

> From: Leon Portman [mailto:[email-masked]]
> Sent: Thursday, May 19, 2011 1:01 PM
> To: Elwell, John; Parthasarathi R (partr); Muthu Arul Mozhi Perumal
> (mperumal); Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat); Henry Lum
> Cc: [email-masked]
> CS?(wasRE:comments on draft-ram-siprec-metadata-04)
> 
> I agree with John. From my point of view MS represent CS media, And it
> can be mapped to zero or more RS m-line via metadata labels.
> 
> Leon
> 
> To: Parthasarathi R (partr); Muthu Arul Mozhi Perumal (mperumal); Ram
> [JRE] I don't follow your reasoning with the above two bullets. I
think
> this gives MS an inconsistent meaning, in that an MS sometimes maps to
> one RS and multiple CS, and in other situations an MS maps to one CS
> and multiple RSs. I would have great difficulty understanding what a
MS
> really is. Up to now we have discussed a MS having a lifetime only in
> the context of a CS and at other times we have discussed a MS having a
> lifetime only in the context of an RS (in this case a 1:1 mapping to
an
> m-line in the SDP).
> [JRE] In this case, what is the defining character of an MS, making it
> the same MS even though it spans many CSs and many RSs? I can't really
> grasp the concept.
> 
> John (as individual)
> 
> 
> >
|--------------------------------------------------------------------
> > > |> >> Alcatel-Lucent and/or its affiliated entities.
|--------------------------------------------------------------------

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 20 May 2011 09:10:44 +0200

> From: Henry Lum [mailto:[email-masked]] 
> Sent: 19 May 2011 19:39
> To: Leon Portman; Elwell, John; Parthasarathi R (partr); 
> Muthu Arul Mozhi Perumal (mperumal); Ram Mohan R (rmohanr); 
> Paul Kyzivat (pkyzivat)
> Cc: [email-masked]
[JRE] Not sure. That might be one way of doing it. So an MS would represent contribution to a medium (e.g., audio, main video) from a single Participant. So for a simple 2-party audio-only call there would be two MS objects, one for Participant 1 and one for Participant 2. This might work, I had not thought of it that way. Certainly it doesn't align with the current metadata model, but of course that can be changed. One problem that would need to be addressed - how to tie together different MS objects that all relate to the same medium (e.g., audio, main video, presentation video). Perhaps they would all share the same "content" attribute.

Another way of looking at it is that an MS models a single medium in the CS, e.g., audio, main video, presentation video. The linkage between an MS object and a Participant object would then point to an m-line in the SDP. To give some examples:

1. The SRC sees only mixed streams and doesn't distinguish the participants. In other words, everything is hidden behind a focus/mixer - it just sees the conference as a single Participant. In this case it would be modelled as a single MS with a single Participant. The linkage between the sole Participant and the MS would point to the m-line.

2. The SRC sees mixed streams but can identify different contributing participants. In this case it would be modelled as a single MS with multiple Participants. Each linkage between a Participant and the MS would point to the same m-line.

3. The SRC sees unmixed streams from different contributing participants, but mixes them itself to send to the SRS as a single mixed stream. Modelling is similar to case 2.

4. The SRC sees unmixed streams from different contributing participants and sends them unmixed as different RTP sessions to the SRS. In this case it would be modelled as a single MS with multiple Participants. Each linkage between a Participant and the MS would point to a different m-line.

5. The SRC sees unmixed streams from different contributing participants and sends them unmixed using different SSRC values in a single RTP session to the SRS. In this case it would be modelled as a single MS with multiple Participants. Each linkage between a Participant and the MS would point to the same m-line. There would also need to be a mechanism for tying a linkage to a particular SSRC value.

> implicit participants should terminate whenever the MS 
[JRE] Sounds reasonable.

John

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Sun, 22 May 2011 09:07:36 -0700

Hi John,

I viewed this a bit differently. Please see inline.

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John
> Sent: Friday, May 20, 2011 12:11 AM
> To: Henry Lum; Leon Portman; Parthasarathi R (partr); Muthu Arul Mozhi
Perumal (mperumal); Ram Mohan R
> (rmohanr); Paul Kyzivat (pkyzivat)
> Cc: [email-masked]
CS?(wasRE:comments on draft-ram-siprec-
> metadata-04)
> [JRE] Not sure. That might be one way of doing it. So an MS would
represent contribution to a medium
> (e.g., audio, main video) from a single Participant. So for a simple
2-party audio-only call there
> would be two MS objects, one for Participant 1 and one for Participant
2. This might work, I had not
> thought of it that way.

This is consistent with my thinking on the matter.

Certainly it doesn't align with the current metadata model, but of
course that
> can be changed. One problem that would need to be addressed - how to
tie together different MS objects
> that all relate to the same medium (e.g., audio, main video,
presentation video). Perhaps they would
> all share the same "content" attribute.
> 
> Another way of looking at it is that an MS models a single medium in
the CS, e.g., audio, main video,
> presentation video. The linkage between an MS object and a Participant
object would then point to an
> m-line in the SDP. To give some examples:
> 
> 1. The SRC sees only mixed streams and doesn't distinguish the
participants. In other words,
> everything is hidden behind a focus/mixer - it just sees the
conference as a single Participant. In
> this case it would be modelled as a single MS with a single
Participant. The linkage between the sole
> Participant and the MS would point to the m-line.

Sounds good.

> 2. The SRC sees mixed streams but can identify different contributing
participants. In this case it
> would be modelled as a single MS with multiple Participants. Each
linkage between a Participant and
> the MS would point to the same m-line.

SRC could send mixed stream to SRS, in which case there would be a
single m-line in the RS. SSRC for RTP stream would probably be that of
the SRC, and CSRC would indicate participants. Alternatively, the SRC
could separate them out into multiple streams, either represented as a
single RS m-line with different SSRC for each participant, or a
different m-line for each participant.
 
> 3. The SRC sees unmixed streams from different contributing
participants, but mixes them itself to
> send to the SRS as a single mixed stream. Modelling is similar to case
2.

SRC could send mixed stream to SRS, in which case there would be a
single m-line in the RS. SSRC for RTP stream would probably be that of
the SRC, and CSRC would indicate participants.

> 4. The SRC sees unmixed streams from different contributing
participants and sends them unmixed as
> different RTP sessions to the SRS. In this case it would be modelled
as a single MS with multiple
> Participants. Each linkage between a Participant and the MS would
point to a different m-line. 
 
I was expecting this to be modeled as multiple different MS. The SRC
would send them as multiple streams, either represented as a single RS
m-line with different SSRC for each participant, or a different m-line
for each participant.

> 5. The SRC sees unmixed streams from different contributing
participants and sends them unmixed using
> different SSRC values in a single RTP session to the SRS. In this case
it would be modelled as a
> single MS with multiple Participants. Each linkage between a
Participant and the MS would point to the
> same m-line. There would also need to be a mechanism for tying a
linkage to a particular SSRC value.

That would be the most lightweight and efficient way, but the SRC could
alter it and represent it differently to the RS, if desired.

Cheers,
Charles

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 23 May 2011 04:04:24 +0530

Hi all,

Please read inline.

Thanks
Partha

-----Original Message-----
From: Henry Lum [mailto:[email-masked]] 
Sent: Friday, May 20, 2011 12:09 AM
To: Leon Portman; Elwell, John; Parthasarathi R (partr); Muthu Arul
Mozhi Perumal (mperumal); Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [siprec] Does MS have life outside a particular
CS?(wasRE:comments on draft-ram-siprec-metadata-04)

I agree with John that a recording session transports recorded streams
and are already described in the SIP session so there is no need to
model recorded streams in the metadata model. 

<Partha> Intention of Metadata model is not to directly map with
metadata format. Metadata model shows how SRS view the metadata.
Metadata may be received as part of RS dialog or RS SDP or new
(Metadata) XML. The reason for model is to view the metadata as a whole
from SRS point of view and not defining the exact 1:1 mapping on the
format. 

I agree that RS SDP shall be used as some of the metadata attributes
like codec parameters. Start & stop time has to defined in Metadata XML
("stream") as it is not possible to provide this CS media information
using RS SDP. Media stream reference ("label") attribute in MS provide
the linkage between RS SDP and other MS attributes.  </Partha>

MS in the metadata model, on the other hand, explains a media stream
that is part a CS, and the recorded streams in the RS just refer to
which MS in the model is actually being recorded. When we record unmixed
streams as a single m-line in the RS, I think we should model as
multiple MS in the metadata model but all the MS would refer to the same
label in the recorded stream. 

<Partha> I'll respond to this question in the extended mail thread by
John & Charles </Partha>

When we relate a MS directly to a CS, I think it implicitly means that a
CS owns some sort of media sources that generates media.
 
<Partha> The discussion makes me to think once again about "CS --
Participant -- Media stream" relation rather than having the current
form of "CS -- Participant, CS--Media stream and Participant--Media
stream". The originally model has only CS-participant-Media stream but
it was changed to handle the cases wherein Media stream is not part of
any CS participants but part of CS. Now, we agreed upon not to have any
participant without CS and model has to be upgraded for MS accordingly.
IMO, It shall be changed back to CS--Participant--Media stream. Please
let me know your opinion here. </Partha>

In other words, CS owns some automated participants as media sources but
we don't explicitly model them. I am okay with this definition since the
SRC can choose to model this either way - meaning if there is need to
show what the CS is doing to the media sources then the SRC can model a
participant that generates the media to explain what it is. These
implicit participants should terminate whenever the MS terminates or the
CS terminates.

Henry

> can be mapped to zero or more RS m-line via metadata labels.

<Partha> IMO, MS represent participant media (which span across multiple
CS in case of CSG) if we provide direct relationship with participant.
MS will map to one RS m-line via metadata labels. </Partha>

think

MS
> really is. 

<Partha> In case of un-mixed stream, MS is directly associated with a
particular participant which span across multiple CS within CSG. In case
of mixed stream, multiple participants are linked to MS, participant
shall added/removed within MS, MS shall span across CS and associated
with CSG. </Partha>

Up to now we have discussed a MS having a lifetime only in 

an
> m-line in the SDP).

<Partha> All the time, MS lifetime is within single CSG. </Partha>

> > local to a Participant, but it may be feasible to make it local to a

> > CS.

> > > |> and/or its affiliated entities.

------------------------------------------------------------------------
-------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain
confidential and proprietary information of Alcatel-Lucent and/or its
affiliated entities. Access by the intended recipient only is
authorized. Any liability arising from any party acting, or refraining
from acting, on any information contained in this e-mail is hereby
excluded. If you are not the intended recipient, please notify the
sender immediately, destroy the original transmission and its
attachments and do not disclose the contents to any other person, use it
for any purpose, or store or copy the information in any medium.
Copyright in this e-mail and any attachments belongs to Alcatel-Lucent
and/or its affiliated entities.

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 23 May 2011 04:43:57 +0530

Hi all,

Please read inline.

Thanks
Partha 

-----Original Message-----
From: Charles Eckel (eckelcu) 
Sent: Sunday, May 22, 2011 9:38 PM
To: Elwell, John; Henry Lum; Leon Portman; Parthasarathi R (partr);
Muthu Arul Mozhi Perumal (mperumal); Ram Mohan R (rmohanr); Paul Kyzivat
(pkyzivat)
Cc: [email-masked]
Subject: RE: [siprec] Does MS have life outside a particular
CS?(wasRE:comments on draft-ram-siprec-metadata-04)

Hi John,

> Perumal (mperumal); Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
> Cc: [email-masked]
> > I agree with John that a recording session transports recorded 
> > streams and are already described in the SIP session so there is no 
> > need to model recorded streams in the metadata model. MS in the 
> > metadata model, on the other hand, explains a media stream that is 
> > part a CS, and the recorded streams in the RS just refer to which MS

> > in the model is actually being recorded. When we record unmixed 
> > multiple MS in the metadata model but all the MS would refer to the 
> > same label in the recorded stream.
> represent contribution to a medium (e.g., audio, main video) from a 
> single Participant. So for a simple 2-party audio-only call there 
2. This might work, I had not thought of it that way.

<Partha> Participant linkage with MS does the same. Label attribute
(media stream attribute) is one of the attribute in MS and not the only
attribute. In case of format, <send> element in participant meets this
requirement. </Partha>

> tie together different MS objects that all relate to the same medium 
> (e.g., audio, main video, presentation video). Perhaps they would all
share the same "content" attribute.
<Partha> Please clarify more. I'm not getting the exact point here.
</Partha>

> the CS, e.g., audio, main video, presentation video. The linkage 
> between an MS object and a Participant object would then point to an
m-line in the SDP.

<Partha> participant shall link m-line in the SDP through MS rather than
direct link. It provides better abstraction. In case of only direct
relationship with MS and participant to m-line using label attribute and
no linkage between MS and participant, the deriving linkage between MS
to participant will be tough in few scenarios. Also, Linkage between
participant and MS is redundant in case linkage exists between
participant and MS  </Partha>

 To give some examples:
> participants. In other words, everything is hidden behind a 
> focus/mixer - it just sees the conference as a single Participant. In 
Participant. The linkage between the sole Participant and the MS would
point to the m-line.

Sounds good.

> participants. In this case it would be modelled as a single MS with 
> multiple Participants. Each linkage between a Participant and the MS
would point to the same m-line.

<Partha> In both examples, Even though same number of linkage, the
relationship with participant and MS needs more search with this
proposal. This could be modeled in a better way </Partha>

<Partha> your alternative example looks similar to unmixed streams.
Please correct  me if I'm wrong </Partha>

> participants, but mixes them itself to send to the SRS as a single
mixed stream. Modelling is similar to case 2.

<Partha> In case of mixed stream, exact participant who contributes to
the specific timeframe is not well known. Participant information in
metadata will help to understand the list of contributing sources. There
is no specific requirement to look into CSRC. Please clarify in case I'm
missing something. </Partha>

> participants and sends them unmixed as different RTP sessions to the 
> SRS. In this case it would be modelled as a single MS with multiple
Participants. Each linkage between a Participant and the MS would point
to a different m-line.

<Partha> Agree with Charles. I'm seeing them as different MS </Partha>

> participants and sends them unmixed using different SSRC values in a 
> single RTP session to the SRS. In this case it would be modelled as a 
Participant and the MS would point to the same m-line. There would also
need to be a mechanism for tying a linkage to a particular SSRC value.

<Partha> In all the example, there is duplicate linkage with m-line and
participant. The missing point is the linkage between participant and
MS. </Partha>

Cheers,
Charles

> 
> >
> > When we relate a MS directly to a CS, I think it implicitly means 
> > that a CS owns some sort of media sources that generates media. In 
> > other words, CS owns some automated participants as media sources 
> > but we don't explicitly model them. I am okay with this definition 
> > since the SRC can choose to model this either way - meaning if there

> > is need to show what the CS is doing to the media sources then the 
> > SRC can model a participant that generates the media to explain what

> > it is. These implicit participants should terminate whenever the MS 
> > terminates or the CS terminates.
> [JRE] Sounds reasonable.
> 
> John
> 
> >
> > Henry
> >

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 23 May 2011 11:19:10 +0200

Charles,

I see that my point 2 was rather ambiguous. I said:
"2. The SRC sees mixed streams but can identify different contributing participants."
What I meant was that the SRC is aware of (by means of the conference event package, for example) the identities of a number of participants contributing to the stream, but is not aware of their particular contributions. However, I had not considered that the different contributors might be known through CSRC. So I agree this introduces further possibilities.

John (as individual)

> From: Charles Eckel (eckelcu) [mailto:[email-masked]] 
> Sent: 22 May 2011 17:08
> To: Elwell, John; Henry Lum; Leon Portman; Parthasarathi R 
> (partr); Muthu Arul Mozhi Perumal (mperumal); Ram Mohan R

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 23 May 2011 11:19:38 +0200

> Sent: 23 May 2011 00:14
> To: Charles Eckel (eckelcu); Elwell, John; Henry Lum; Leon 
> Portman; Muthu Arul Mozhi Perumal (mperumal); Ram Mohan R 
> Paul Kyzivat
> Muthu Arul 
[JRE] Several participants are contributing to a single medium (e.g., audio, main video, presentation video, current speaker video) and those contributions get delivered separately to the SRS. I understand you favour modelling this as separate Media Stream objects. The point I am trying to make is that MS objects relating to the same medium probably need to be tied together somehow, so that the SRS recognises them as belonging to the same medium, rather than to different media.

> participant and MS  </Partha>
[JRE] I agree there would not be a direct link from Participant object to m-line - I don't think anyone proposed that.

> <Partha> Agree with Charles. I'm seeing them as different MS </Partha>
[JRE] OK - perhaps that works. To get this sorted out (I will go with the majority) I am starting a separate thread.

> participant. The missing point is the linkage between participant and
[JRE] I don't understand. There will always need to be linkage (association) between a Participant and a Media Stream.

John (as individual)

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 23 May 2011 15:39:45 +0530

John 

================================================
>One problem that would need to be addressed
> - how to
[JRE] Several participants are contributing to a single medium (e.g.,
audio, main video, presentation video, current speaker video) and those
contributions get delivered separately to the SRS. I understand you
favour modelling this as separate Media Stream objects. The point I am
trying to make is that MS objects relating to the same medium probably
need to be tied together somehow, so that the SRS recognises them as
belonging to the same medium, rather than to different media.
=================================================

<Partha> Thanks for the clarification. I skimmed through 'content'
attribute spec (RFC 4796) but it does not seems to help grouping but it
will help to differentiate the media. In case of multiple media stream
has to be grouped together, we will explore to use some grouping
mechanism options like SDP grouping.

Charles earlier proposed to tie together in the single m-line and use
CSRC to differentiate the contributors within the single medium. The
caveat with that approach is that SRC will not be able to acts as RTP
translator. Due to this caveat, I won't prefer to have SIPREC's only
mechanism as single MS for specific media type within multiple
participant.

The mixed stream for specific media type will tie-together for several
contributors but it will work only for audio and not for video, so it
will not be taken as a generic approach.

My other queries in the mail thread are due to the my misinterpretation
of your proposal, so Pls ignore it.  </Partha> 

Thanks
Partha

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 23 May 2011 14:33:32 +0200

Partha,

I don't think we need an SDP mechanism for grouping MS objects belonging to the same medium - the metadata can provide that linkage somehow.

John (as individual)

> Sent: 23 May 2011 11:10
> To: Elwell, John; Charles Eckel (eckelcu); Henry Lum; Leon

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 23 May 2011 08:24:23 -0700

Hi Partha,

Please see inline for answers to the questions you raised regarding the
comments I added previously.

> From: Parthasarathi R (partr)
> Sent: Sunday, May 22, 2011 4:14 PM
> To: Charles Eckel (eckelcu); 'Elwell, John'; 'Henry Lum'; 'Leon
Portman'; Muthu Arul Mozhi Perumal
> (mperumal); Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
> Cc: [email-masked]'
> To: Elwell, John; Henry Lum; Leon Portman; Parthasarathi R (partr);
Muthu Arul Mozhi Perumal
> (mperumal); Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
> Cc: [email-masked]
> > would be two MS objects, one for Participant 1 and one for
Participant 2. This might work, I had not
> <Partha> Participant linkage with MS does the same. Label attribute
(media stream attribute) is one of
> the attribute in MS and not the only attribute. In case of format,
<send> element in participant meets
> this requirement. </Partha>
> 
course that
> > (e.g., audio, main video, presentation video). Perhaps they would
all share the same "content"
</Partha>
m-line in the SDP.
> 
> <Partha> participant shall link m-line in the SDP through MS rather
than direct link. It provides
> better abstraction. In case of only direct relationship with MS and
participant to m-line using label
> attribute and no linkage between MS and participant, the deriving
linkage between MS to participant
> will be tough in few scenarios. Also, Linkage between participant and
MS is redundant in case linkage
> exists between participant and MS  </Partha>
> 
>  To give some examples:
> >
Participant. The linkage between the
> sole Participant and the MS would point to the m-line.
> 
> Sounds good.
> 
> <Partha> In both examples, Even though same number of linkage, the
relationship with participant and
> MS needs more search with this proposal. This could be modeled in a
better way </Partha>
> SRC could send mixed stream to SRS, in which case there would be a
single m-line in the RS. SSRC for
> RTP stream would probably be that of the SRC, and CSRC would indicate
participants. Alternatively, the
> SRC could separate them out into multiple streams, either represented
as a single RS m-line with
> different SSRC for each participant, or a different m-line for each
participant.
> <Partha> your alternative example looks similar to unmixed streams.
Please correct  me if I'm wrong
> </Partha>

Yes. In this case, the SRC sees a mixed stream within the CS, and can
represent it as either a single mixed stream, or one of more unmixed
streams within the RS.
 
> > participants, but mixes them itself to send to the SRS as a single
mixed stream. Modelling is
> similar to case 2.
single m-line in the RS. SSRC for
> RTP stream would probably be that of the SRC, and CSRC would indicate
participants.
> <Partha> In case of mixed stream, exact participant who contributes to
the specific timeframe is not
> well known. Participant information in metadata will help to
understand the list of contributing
> sources. There is no specific requirement to look into CSRC. Please
clarify in case I'm missing
> something. </Partha>

Within a mixed stream, the CSRC may be used to indicate the contributing
streams. Changes to the CSRC values can be as frequent as required to
indicate changes among the actual contributors. 

Cheers,
Charles

> > SRS. In this case it would be modelled as a single MS with multiple
Participants. Each linkage
> between a Participant and the MS would point to a different m-line.
> 
would send them as multiple
> streams, either represented as a single RS m-line with different SSRC
for each participant, or a
> > single MS with multiple Participants. Each linkage between a
Participant and the MS would point to
> the same m-line. There would also need to be a mechanism for tying a
linkage to a particular SSRC
> value.
> 
> <Partha> In all the example, there is duplicate linkage with m-line
and participant. The missing point
> is the linkage between participant and MS. </Partha>
> 
> That would be the most lightweight and efficient way, but the SRC
could alter it and represent it
> differently to the RS, if desired.
> 
> Cheers,
> Charles
> 
> >
> > >

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 23 May 2011 22:32:09 +0530

Hi Charles,

Thanks for the clarification. I agree that CSRC based solution has
better recording information but only the limitation is that SRC has to
acts as RTP endpoint or RTP mixer.

Thanks
Partha 

-----Original Message-----
From: Charles Eckel (eckelcu) 
Sent: Monday, May 23, 2011 8:54 PM
To: Parthasarathi R (partr); 'Elwell, John'; 'Henry Lum'; 'Leon
Portman'; Muthu Arul Mozhi Perumal (mperumal); Ram Mohan R (rmohanr);
Paul Kyzivat (pkyzivat)
Cc: [email-masked]'
Subject: RE: [siprec] Does MS have life outside a particular
CS?(wasRE:comments on draft-ram-siprec-metadata-04)

Hi Partha,

> Portman'; Muthu Arul Mozhi Perumal (mperumal); Ram Mohan R (rmohanr); 
> Paul Kyzivat (pkyzivat)
> Cc: [email-masked]'
> Muthu Arul Mozhi Perumal (mperumal); Ram Mohan R (rmohanr); Paul 
> Kyzivat (pkyzivat)
> Cc: [email-masked]
> > To: Henry Lum; Leon Portman; Parthasarathi R (partr); Muthu Arul 
> > > To: Leon Portman; Elwell, John; Parthasarathi R (partr); Muthu 
> > > Arul Mozhi Perumal (mperumal); Ram Mohan R (rmohanr); Paul Kyzivat
> > > (pkyzivat)
> > > Cc: [email-masked]
> > > streams and are already described in the SIP session so there is 
> > > no need to model recorded streams in the metadata model. MS in the

> > > part a CS, and the recorded streams in the RS just refer to which 
> > > MS in the model is actually being recorded. When we record unmixed

> > > multiple MS in the metadata model but all the MS would refer to 
> > > the same label in the recorded stream.
> (media stream attribute) is one of the attribute in MS and not the 
> only attribute. In case of format, <send> element in participant meets

m-line in the SDP.
> than direct link. It provides better abstraction. In case of only 
> direct relationship with MS and participant to m-line using label 
> linkage between MS to participant will be tough in few scenarios. 
> Also, Linkage between participant and MS is redundant in case linkage 
> > focus/mixer - it just sees the conference as a single Participant. 
> > In this case it would be modelled as a single MS with a single 
> > 2. The SRC sees mixed streams but can identify different 
> > contributing participants. In this case it would be modelled as a 
Participant and the MS would point to the same m-line.

 

> metadata will help to understand the list of contributing sources. 
> There is no specific requirement to look into CSRC. Please clarify in 
> case I'm missing something. </Partha>

Cheers,
Charles

for each participant.

> > single RTP session to the SRS. In this case it would be modelled as 
> > a single MS with multiple Participants. Each linkage between a 
> and participant. The missing point is the linkage between participant 
> and MS. </Partha>
> 
> could alter it and represent it differently to the RS, if desired.
> 
> Cheers,
> Charles
> 
> >
> > >

> > > since the SRC can choose to model this either way - meaning if 
> > > there is need to show what the CS is doing to the media sources 
> > > then the SRC can model a participant that generates the media to 
> > > explain what it is. These implicit participants should terminate 
> > > whenever the MS terminates or the CS terminates.
> > [JRE] Sounds reasonable.
> >
> > John
> >
> > >
> > > Henry
> > >