Subject: [siprec] FW: Do we need to model participants not part of CS butassociated with Media Stream block in the metadata model ? (was RE: Partial updates and identifiers)

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 15 Apr 2011 15:26:19 +0530

I request people to provide inputs on this and help to take it to a
closure. This issue has been open for several months now.

Ram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ram Mohan R (rmohanr)
Sent: Tuesday, April 12, 2011 3:04 PM
To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R (partr); Paul
Kyzivat (pkyzivat); [email-masked]
Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr)
Subject: [siprec] Do we need to model participants not part of CS but
associated with Media Stream block in the metadata model ? (was RE:
Partial updates and identifiers)

Renaming the mail thread to discussion to this specific issue -
"Metadata for participants not part of CS" which we have been discussing
from several weeks.

Please continue the other issues in original thread and lets use this
thread to close this issue. I would request people to give inputs for
this issue on this thread and take it to a conclusion.

We(Authors of Metadata model) included participants that are not part of
CS to imply:
- Participants that does NOT contribute to signaling in CS but
contributes to media 
The intent is to give more flexibility in the metamodel to represent
these types of participants.

Following are some of use case where this can happen-

Use-Case 1: A conference where one of the participants is a SRC. In
these case the Focus which talks to this SRC becomes part of CS
contributing signaling as well as media. However the media includes
media from other participants that are not part of CS. Please note SRC
has to subscribe to conf event packet to get this information (which may
not be always feasible).

Use-Case 2: one UA in CS works in 3pcc mode to acquire an MoH media
stream,  this might be reflected as unique source for media stream
without   having a reported signaling relationship to it. E.g is given
here by Henry Lum
http://www.ietf.org/mail-archive/web/siprec/current/msg01372.html

In some sense these participants are *still* part of CS as they
contribute to CS media.

There are three approaches I can see-
Don't model the participants that does not contribute signaling in CS
and only contribute Media
Model these participants as not part of CS in the model but associated
with Media Stream block ( current approach)
Model these participants to be associated with CS but have the
association labeled as "indirect participant" 

Let me know your thoughts.

Thanks,
Ram

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Elwell, John
> Sent: Tuesday, April 12, 2011 12:13 PM
> To: Charles Eckel (eckelcu); Parthasarathi R (partr); Paul Kyzivat
> (pkyzivat); [email-masked]
> Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr)
> Subject: Re: [siprec] Partial updates and identifiers
> 
> I think the attached message was the last in that thread. So I don't
> really think we had closure.
> 
> John
> 
> > -----Original Message-----
> > From: Charles Eckel (eckelcu) [mailto:[email-masked]]
> > Sent: 11 April 2011 23:53
> > To: Elwell, John; Parthasarathi R (partr); Paul Kyzivat (pkyzivat);
> > [email-masked]
> > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); Hadriel
> > Kaplan
> > Subject: RE: [siprec] Partial updates and identifiers
> >
> > Hi John,
> >
> > I have attached the last e-mail I have from the thread in which I
> > first raised this issue. Unfortunately, I do not have the e-mail
with
> > the ultimate agreement, but maybe someone else does or this will
help
> > prompt some memories.
> >
> > Cheers,
> > Charles
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Elwell, John
> > > Sent: Monday, April 11, 2011 9:46 AM
> > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat);
> > [email-masked]
> > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr);
> Hadriel
> > Kaplan
> > > Subject: Re: [siprec] Partial updates and identifiers
> > >
> > > Partha,
> > >
> > > Thanks for reminding me - I now recall the discussion some
> > weeks/months ago about the participants
> > > obtained from the conference event package. I was never
> particularly
> > comfortable with the fact these
> > > were not considered part of the CS. While that might be
> > correct if we
> > consider the CS to be the SIP
> > > dialog between the SRC and the conference focus, taking a
> > broader view
> > of CS those participants behind
> > > the focus could be considered part of the CS. I don't particularly
> > want to open up the old discussion
> > > if people are happy with what we have, but something doesn't seem
> > quite right to me.
> > >
> > > For example, if these "participants" are not considered part of
the
> > CS, and if we don't have specific
> > > information about their involvement in media streams, do they
> really
> > merit being considered
> > > Participant objects?
> > >
> > > In other words, two possible approaches are:
> > >
> > > 1) The CS extends only as far as the focus / mixer. The
> > focus/mixer is
> > a "Participant" and the users
> > > behind the focus are not separate Participants but are just
> > additional
> > data associated with the
> > > focus/mixer Participant. The only Media Streams we are
> > concerned with
> > are between the mixer and the
> > > SRC.
> > >
> > > 2) The CS extends beyond the focus/mixer to users learned via the
> > conference event package, each of
> > > those users is a separate Participant object, and we are concerned
> > with Media Stream objects that
> > > those participants send and receive. I am not sure how feasible
> this
> > approach is, because I am not
> > > sure that the SRC can obtain enough information about media
> > streams at
> > users behind the focus/mixer.
> > >
> > > It seems the present solution is somewhere between the two, which
> is
> > why I am uncomfortable.
> > >
> > > Regards,
> > >
> > > John (as individual)
> > >
> > >
> > > > -----Original Message-----
> > > > From: Parthasarathi R (partr) [mailto:[email-masked]]
> > > > Sent: 11 April 2011 10:29
> > > > To: Elwell, John; Paul Kyzivat (pkyzivat); [email-masked]
> > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand
> > > > (jhildebr)
> > > > Subject: RE: [siprec] Partial updates and identifiers
> > > >
> > > > John,
> > > >
> > > > Please read inline.
> > > >
> > > > Thanks
> > > > Partha
> > > >
> > > > -----Original Message-----
> > > > From: Elwell, John [mailto:[email-masked]]
> > > > Sent: Monday, April 11, 2011 2:11 PM
> > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat);
> > [email-masked]
> > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand
> > > > (jhildebr)
> > > > Subject: RE: [siprec] Partial updates and identifiers
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Parthasarathi R (partr) [mailto:[email-masked]]
> > > > > Sent: 11 April 2011 08:35
> > > > > To: Elwell, John; Paul Kyzivat (pkyzivat); [email-masked]
> > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe
> Hildebrand
> > > > > (jhildebr)
> > > > > Subject: RE: [siprec] Partial updates and identifiers
> > > > >
> > > > > John,
> > > > >
> > > > > As I mentioned below, stream block will be unique
> > within CS, (not
> > > > > required to be unique across multiple CS) and so, xml:id or
> > > > enhancing
> > > > > the normative statement of RFC 4574 label attribute to be
> unique
> > > > > within CS will serve the purpose. I'm fine with any of the
> above
> > > > > mentioned id.
> > > > > Please note that RFC 4574 "label" attribute is the nature
> > > > data for RS
> > > > > dialog.
> > > > >
> > > > > In case participant within CS, xml:id will serve the purpose
> but
> > we
> > > > > need to get more clarity about participants who are not
> > > > part of CS but
> > > >
> > > > > within RS.
> > > > [JRE] If I understand the figure in section 3 of metadata-04
> > > > correctly, a Participant can have a relationship with a CS, but
> no
> > > > direct relationship with an RS.
> > > >
> > > > <Partha> Sorry, I mixed up my statement with the latest update
of
> > > > making CSG optional. As per Sec 3 of metadata-04, participant
has
> > > > direct relationship with CSG in case CS is left completely
> > > > unattached. In case CSG is optional, then participant will have
> > > > direct relationship with RS in case there is no relationship
> > > > between CS and participant.
> > > > </Partha>
> > > >
> > > >  So a participant that does not have a relationship with a CS is
> > left
> > > > completely unattached, unless it has a relationship with a Media
> > > > Stream (which always has a relationship with a CS). So to
> > > > summarize:
> > > > - a Participant can have a direct relationship with a CS; or
> > > > - a Participant can have an indirect relationship with a CS (via
> a
> > > > Media Stream); <Partha> agreed </Partha>
> > > > - a Participant can have no relationship with a CS, and
> > therefore no
> > > > relationship with an RS.
> > > > Do we really need this last case?
> > > >
> > > > <Partha> I'm happy if the last case is not required because it
> > > > simplify the solution and there is no need of unique id for
> > > > participant. But SRS implementers may prefer to have
relationship
> > > > with participant and RS. I wish more opinion before taking
> > > > decision whether to remove the last case </Partha>
> > > >
> > > > > Because CS may span across different RS how about the
> > > > participant who
> > > > > are not part of CS?
> > > > [JRE] I don't understand the words "Because CS may span across
> > > > different RS", because in the rest of the sentence you are
> talking
> > > > about a Participant that is not part of a CS.
> > > >
> > > > > Ex: One of the user in the conference acts as SRC, fetch
> > > > participant
> > > > > info using conferene package and new RS is created
> > during initial
> > > > > conference creation and hold&resume of a user within CS.
> > > > [JRE] I am not sure what you are trying to say here. I would
> > > > consider a user whose identity is obtained via a conference
event
> > > > package as being part of the CS.
> > > >
> > > > <Partha> I'm trying to give the example where participant is not
> > > > associated with CS directly but related to CSG (/RS). This
> > > > scenario was considered as a blocking in -03 version of
metadata.
> > > > I'm not arguing to have this scenario but it is major concern
for
> > > > few folks.
> > > >
> > > > CS is between focus and UA, UA acts as SRC, UA receives the
> > > > participant info via conference event package but those
> > > > participants are not related in CS directly (and only focus is
> > > > related) but they contributed for the mixed stream. </Partha>
> > > >
> > > >  That user is sending/receiving Media Streams that are part of a
> > > > CS, or if it isn't sending/receiving Media Streams, what is the
> > > > relevance
> > of
> > > > that Participant?
> > > >
> > > > <Partha> Mixed media stream from focus to UA belongs to the
> > Conference
> > > > event package participants. There participant are not directly
> > > > involved as part of CS. </Partha>  Why would we create a new RS
> > > > for such a participant?
> > > > <Partha> RS is not created for participant. Multiple RS shall be
> > > > created the same CS during the different time frame as shown
> below
> > > >
> > > >            <-------------------CS1------------->
> > > >              <---RS1-->  <---RS2------>
> > > >
> > > > CS1 is between UA (SRC) and focus whereas RS1, RS2 is between UA
> > (SRC)
> > > > and SRS. Here tangling (conference event package) participant
has
> > > > to be grouped together in RS1, RS2 by some means through given
> > > > metadata.
> > The
> > > > question whether this corner has to be solved ? </Partha>
> > > >
> > > > John (as individual)
> > > >
> > > >
> > > >
> > > > >
> > > > > Thanks
> > > > > Partha
> > > > >
> > > > > -----Original Message-----
> > > > > From: Elwell, John [mailto:[email-masked]]
> > > > > Sent: Friday, April 08, 2011 9:36 PM
> > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat);
> > > > [email-masked]
> > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe
> Hildebrand
> > > > > (jhildebr)
> > > > > Subject: RE: [siprec] Partial updates and identifiers
> > > > >
> > > > > Focusing just on participant and stream for the time being,
> > > > do these
> > > > > need to be unique across multiple CSs or not?
> > > > >
> > > > > John
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Parthasarathi R (partr) [mailto:[email-masked]]
> > > > > > Sent: 07 April 2011 10:51
> > > > > > To: Paul Kyzivat (pkyzivat); [email-masked]; Elwell, John
> > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe
> > Hildebrand
> > > > > > (jhildebr)
> > > > > > Subject: RE: [siprec] Partial updates and identifiers
> > > > > >
> > > > > > John,
> > > > > >
> > > > > > Sorry for the lengthy mail but it contains lot of analysis
> and
> > > > > > reasoning for this id approach.
> > > > > >
> > > > > > Adding to Paul's point, I wish to give more background and
> > > > > reason for
> > > > > > these globally unique id. Initially I had the impression
that
> > the
> > > > > > single unique id (RS dialog-id) in the recording (session
> > > > > level) and
> > > > > > some relevant natural id for the rest of the element will
> > > > serve the
> > > > > > purpose.
> > > > > > There are usecases where this assumption fails. Even I have
> > > > > thought of
> > > > >
> > > > > > using "xml:id" instead of URN UUID to avoid long string but
> > > > > xml:id may
> > > > >
> > > > > > not end up with unique value always. Our analysis for URN
> > > > UUID for
> > > > > > each level is as follows and please provide your input in
> case
> > id
> > > > > > shall be
> > > > > > tweaked:
> > > > > >
> > > > > > 1) Recording block: The reason for globally unique id is
> > > > > that multiple
> > > > >
> > > > > > SRC with same id to single SRS.
> > > > > >
> > > > > > Topology:
> > > > > >
> > > > > > SRC1         SRC2
> > > > > >  |            |
> > > > > >  |            ----(RS1-ID1)-----SRS1
> > > > > >  |
> > > > > >   ---(RS2-ID1)------------------SRS1
> > > > > >
> > > > > > In the above topology, it is possible for ID1 is generated
by
> > both
> > > > > > SRC1 and SRC2 at the same time.
> > > > > >
> > > > > > 2) group (CSG) block: Grouping mechanism (Hadriel
> > > > session-id, Paul
> > > > > > Jones
> > > > > > Session-UUID) is outside the scope of SIPREC. URN UUID
> > > > > abstracts the
> > > > > > exact mechanism to SRS and provides the information only
> > > > about the
> > > > > > group of CS from SRC perspective. It possible that group may
> > span
> > > > > > across multiple RS and It is up to SRS to group and view
> > > > as single
> > > > > > recording.
> > > > > > Here, the single level id in the top will fail. The counter
> > > > > argument
> > > > > > is to force the single RS having complete CSG but
> > it*may not* be
> > > > > > possible in SRC implementation. Here, xml:id will not
> > serve the
> > > > > > purpose
> > > > > >
> > > > > > 3) session (CS) block: At the immediate look, session
> > > > falls exactly
> > > > > > under recording block. Use case 3 of
draft-ietf-siprec-req-09
> > > > > > illustrates where CS span across multiple RS. This
> > > > > requirement calls
> > > > > > for unique id in session by which these session shall be
> > > > viewed as
> > > > > > single CS even though there is no group exists among
> > > > them. IMO, in
> > > > > > case session should not have globally unique id, then it is
> > > > > preferred
> > > > > > to remove usecase 3 in the requirement.
> > > > > >
> > > > > > 4) participant block: It needs some id which may be AOR but
> > > > > AOR is not
> > > > >
> > > > > > unique. IMO, xml:id may serve the purpose with session
> > > > > unique id. The
> > > > > > trick exists for participant who are not associated with
> > > > > CS. We shall
> > > > > > discuss and fine tune if required.
> > > > > >
> > > > > > 5) stream block: Label attribute shall be used as unique
> > > > > value but RFC
> > > > > > 4574 does not mandate label attribute has to be unique
across
> > the
> > > > > > dialog or CS and so, it may possible to change within
> > RS and no
> > > > > > normative statement to stop this implementation. IMO,
> > > > > xml:id may serve
> > > > >
> > > > > > the purpose with session unique id. Here as well, We shall
> > > > > discuss and
> > > > >
> > > > > > fine tune if required.
> > > > > >
> > > > > > 6) extensiondata block: This is tracked in the separate
> > > > mail thread
> > > > > > whether unique id is required or not. Let us close this
> > > > as part of
> > > > > > that mail thread.
> > > > > >
> > > > > > Including explicitly Hadriel, Peter, Joe in this mail
> > > > > thread as they
> > > > > > have different view on this ID mechanism.
> > > > > >
> > > > > > I had offline discussion with Hadriel in Prague after
> > > > > SIPREC meeting
> > > > > > and my understanding of his major concern is that how SRS
> > > > > will be able
> > > > >
> > > > > > to design the database in case partial update does not have
> > > > > recording
> > > > > > (top) id information. I'll put more thought
> > processing to close
> > > > > > Hadriel concern of how top id has to be tracked in case
> > > > > partial update
> > > > >
> > > > > > by which SRS implementation will be simplified in terms of
> > > > > aggregation
> > > > >
> > > > > > maintenance.
> > > > > >
> > > > > > Thanks
> > > > > > Partha
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: [email-masked]
> > > > > > [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> > > > > (pkyzivat)
> > > > > > Sent: Thursday, April 07, 2011 12:33 AM
> > > > > > To: [email-masked]
> > > > > > Subject: Re: [siprec] Partial updates and identifiers
> > > > > >
> > > > > > John,
> > > > > >
> > > > > > For the moment we have proposed that the ids be conveyed in
> > > > > the form
> > > > > > of URIs that are globally unique, and specifically that
> > > > > they be UUID
> > > > > > URNs.
> > > > > > There is no dependency on the particular form of the URI,
but
> > > > > > specifying they must be UUID URNs makes it possible to
> > > > perform some
> > > > > > internal optimizations for storage.
> > > > > >
> > > > > > The UUID URN is a pretty inefficient encoding. A UUID can
> > > > > be expressed
> > > > >
> > > > > > in 32 bits, so we could consider retaining UUIDs but alter
> the
> > > > > > encoding if its really an issue. However I am far from
> > > > > convinced that
> > > > > > the size of the IDs is going to be a major issue in the
> > > > > overall size
> > > > > > of messages, so I think its probably premature to worry
about
> > it.
> > > > > >
> > > > > > Because the ids can be expressed in 32 bits, the SRC and
> > > > > SRS can store
> > > > >
> > > > > > them internally that way, thus reducing the runtime cost of
> > > > > > maintaining the data.
> > > > > >
> > > > > > The use of unique ids is a significant part of the overall
> > > > > approach to
> > > > >
> > > > > > formatting updates. If somebody has a different concept
> > > > in mind it
> > > > > > could be useful to have an alternative proposal for the
> > > > > format. If we
> > > > > > had two worked out approaches we could compare the
> > > > > tradeoffs in each.
> > > > > >
> > > > > >   Thanks,
> > > > > >   Paul
> > > > > >
> > > > > > On 4/6/2011 10:24 AM, Elwell, John wrote:
> > > > > > > Much of the discussion on draft-ram-metadata-format
> > in Prague
> > > > > > concerned the mechanism for performing partial updates and
> > > > > the use of
> > > > > > identifiers. The draft permits partial updates by allowing
> > > > > individual
> > > > > > objects (e.g., CS, participant, media stream) to be sent
> > > > > with updated
> > > > > > content, without having to send again other objects that
have
> > not
> > > > > > changed. So, for example, in a large conference, it would
> > > > > be possible
> > > > > > to add or modify an individual participant object without
> > > > having to
> > > > > > send all the other participant objects again. I do not
recall
> > any
> > > > > > opposition to this basic principle.
> > > > > > >
> > > > > > > However, to achieve this, every object requires an
> > > > > > identifier, and it
> > > > > > was asserted that these identifiers need to be globally
> > > > > unique for all
> > > > >
> > > > > > time. Although this might be efficient for updating an
> > individual
> > > > > > object, when sending many objects (e.g., at the start of a
> > > > > CS or when
> > > > > > refreshing the entire metadata), this can make the
> > metadata very
> > > > > > bulky.
> > > > > > It depends, of course, on the format of the identifiers,
> > > > and it was
> > > > > > stated that there could be alternatives to UUID.
> > > > Nevertheless, some
> > > > > > people had concerns. These concerns also extended to the
> > > > > impact on the
> > > > >
> > > > > > database where metadata is stored, since it might not be
> > > > > feasible to
> > > > > > convert to a database-friendly mechanism for linking
> > > > > objects together.
> > > > > > >
> > > > > > > One alternative proposal during the meeting was to have a
> > single
> > > > > > unique identifier at the top level (for the RS) and use
local
> > > > > > identifiers for other objects. Thus when updating a single
> > > > > object, it
> > > > > > would be necessary to include the top level identifier as
> > > > > well as one
> > > > > > or more local identifiers. However, there were also concerns
> > this
> > > > > > might not fulfil actual or perceived future requirements.
> > > > > > >
> > > > > > > Please continue discussion on this.
> > > > > > >
> > > > > > > John (as chair)
> > > > > > > _______________________________________________
> > > > > > > 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
> >
_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 15 Apr 2011 13:04:24 +0200

As an individual, my opinion, which I have pretty much stated before, is that a participant must always be part of a CS. A couple of situations have been mentioned where alternatives might be required, but I don't believe so.

1. Conferences. I think depending what view the SRC has of the CS, there are two situations:

(a) The SRC sees all parties in the conference and has visibility of what Media Streams each party sends and receives. In this case, I think the whole conference can be modelled as a CS and each party can be modelled as a Participant in that CS. Such a view will typically be feasible when the SRC is located at a conference focus/mixer (e.g., an MCU).

(b) The SRC sees the conference focus mixer as a party but has limited information about parties behind the focus/mixer. In this case I think the SRC can regard the CS as terminating at the conference (focus/mixer), with the conference a Participant in that CS. Information about parties behind the conference may or may not be available, in which case they can be additional attributes of the conference Participant object. One typical case will be where the SRC is located at a UA of one of the conference parties, or at a B2BUA between the focus/mixer and a party UA. In that case the CS would have two Participants: the party concerned and the conference. Am extreme case is where the conference is the sole Participant and just records Media Streams sent by the conference to parties in the conference.

Hybrid situations can occur, e.g., for cascaded conferences, where participants at one conference are modelled as Participants but other conferences are just modelled each as a single Participant.

2. IVR and similar. I would model the Media Server as a Participant in the CS, i.e., there is a CS between the Media Server and the caller.

John

> [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
> Sent: 15 April 2011 10:56
> To: [email-masked]
> Subject: [siprec] FW: Do we need to model participants not
> part of CS butassociated with Media Stream block in the
> metadata model ? (was RE: Partial updates and identifiers)
>
> [mailto:[email-masked]] On Behalf
> Of Ram Mohan R (rmohanr)
> [mailto:[email-masked]] On
> > > Behalf Of Elwell, John
> > > > > > From: Elwell, John
> [mailto:[email-masked]]

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 15 Apr 2011 17:28:11 +0530

John point of view looks reasonable to me because CS is not directly
associated with dialogs but instead it represents session with the list
of participant involved in it. 

In case of participant list received through conference package to SRC
with UA, those multiple participants from focus shall be represented as
individual participant block who are pointed to single mixed media
stream metadata block and all participant belongs within single
conference  CS in this scenario. The model is as follows (part in the
diagram represents participant):

      RS
       |
      CS-------------------------------
       |                               |
 -----------------------             part5(SRC)
|        |      |       |              | 
|        |      |       |            media stream2
part1  part2   part3   part4
|        |       |      |
-------------------------
          |
    Media stream1

Thanks
Partha 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Elwell, John
Sent: Friday, April 15, 2011 4:34 PM
To: Ram Mohan R (rmohanr); [email-masked]
Subject: Re: [siprec] FW: Do we need to model participants not part ofCS
butassociated with Media Stream block in the metadatamodel ? (was RE:
Partial updates and identifiers)

As an individual, my opinion, which I have pretty much stated before, is
that a participant must always be part of a CS. A couple of situations
have been mentioned where alternatives might be required, but I don't
believe so.

1. Conferences. I think depending what view the SRC has of the CS, there
are two situations:

(a) The SRC sees all parties in the conference and has visibility of
what Media Streams each party sends and receives. In this case, I think
the whole conference can be modelled as a CS and each party can be
modelled as a Participant in that CS. Such a view will typically be
feasible when the SRC is located at a conference focus/mixer (e.g., an
MCU).

(b) The SRC sees the conference focus mixer as a party but has limited
information about parties behind the focus/mixer. In this case I think
the SRC can regard the CS as terminating at the conference
(focus/mixer), with the conference a Participant in that CS. Information
about parties behind the conference may or may not be available, in
which case they can be additional attributes of the conference
Participant object. One typical case will be where the SRC is located at
a UA of one of the conference parties, or at a B2BUA between the
focus/mixer and a party UA. In that case the CS would have two
Participants: the party concerned and the conference. Am extreme case is
where the conference is the sole Participant and just records Media
Streams sent by the conference to parties in the conference.

Hybrid situations can occur, e.g., for cascaded conferences, where
participants at one conference are modelled as Participants but other
conferences are just modelled each as a single Participant.

2. IVR and similar. I would model the Media Server as a Participant in
the CS, i.e., there is a CS between the Media Server and the caller.

John

> Subject: [siprec] FW: Do we need to model participants not part of CS 
> butassociated with Media Stream block in the metadata model ? (was RE:

> To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R (partr); 
> Paul Kyzivat (pkyzivat); [email-masked]
> "Metadata for participants not part of CS" which we have been 
> discussing from several weeks.
>
> We(Authors of Metadata model) included participants that are not part 
> of CS to imply:
> contributes to media The intent is to give more flexibility in the 
> metamodel to represent these types of participants.
>

> has to subscribe to conf event packet to get this information (which 
> may not be always feasible).
>
> and only contribute Media Model these participants as not part of CS 
> in the model but associated with Media Stream block ( current 
> approach) Model these participants to be associated with CS but have 
> the association labeled as "indirect participant"
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 15 Apr 2011 20:34:17 +0530

I am ok with associating participants behind a UA [ for case where UA is
capable of learning them] in CS as part of that CS in the model/format.
One question I have is, Do we need to distinguish these participants
from the others by having some attributes as part of participant block?
Or is it sufficient if we just treat them as any other participants of
CS.

There are three categories of participants:
Participants who contribute both signaling and media to CS
Participants who contribute only media in the CS [ like the below case]
Participants who contribute only signaling to CS [e.g. 3pcc controller]

Ram

> From: Parthasarathi R (partr)
> Sent: Friday, April 15, 2011 5:28 PM
> To: Elwell, John; Ram Mohan R (rmohanr); [email-masked]
> Subject: RE: [siprec] FW: Do we need to model participants not part
> ofCS butassociated with Media Stream block in the metadatamodel ? (was
> RE: Partial updates and identifiers)
> 
> Subject: Re: [siprec] FW: Do we need to model participants not part
> ofCS butassociated with Media Stream block in the metadatamodel ? (was
> RE: Partial updates and identifiers)
> 
> As an individual, my opinion, which I have pretty much stated before,
> is that a participant must always be part of a CS. A couple of
> situations have been mentioned where alternatives might be required,
> but I don't believe so.
> 
> (focus/mixer), with the conference a Participant in that CS.
> Information about parties behind the conference may or may not be
> available, in which case they can be additional attributes of the
> conference Participant object. One typical case will be where the SRC
> is located at a UA of one of the conference parties, or at a B2BUA
> between the focus/mixer and a party UA. In that case the CS would have
> two Participants: the party concerned and the conference. Am extreme
> case is where the conference is the sole Participant and just records
> Media Streams sent by the conference to parties in the conference.
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 15 Apr 2011 17:26:49 +0200

> From: Ram Mohan R (rmohanr) [mailto:[email-masked]]
> Sent: 15 April 2011 16:04
> To: Parthasarathi R (partr); Elwell, John; [email-masked]
> Subject: RE: [siprec] FW: Do we need to model participants
> not part ofCS butassociated with Media Stream block in the
> metadatamodel ? (was RE: Partial updates and identifiers)
>
[JRE] We could treat them as other Participants, but if we don't have information about the media they are sending receiving and therefore all media is seen by the SRC as being sent/received by the conference UA, then I don't really see it makes sense to treat them as separate Participant objects.

> Participants who contribute only signaling to CS [e.g. 3pcc
[JRE] I don't think this distinction is particularly relevant to what gets sent to the SRS, stored, and subsequently played back. The information that really needs to be captured is which participants send/receive which media, and signalling. Signalling is just part of the CS mechanism that has no relevance to what gets recorded and played back. I don't see why a 3PCC controller would be considered a Participant.

John (as individual)

> > > > > I have attached the last e-mail I have from the
> thread in which
> I
> > > > > > > <Partha> I'm happy if the last case is not
> required because
> > it
> > > > > > > participants are not related in CS directly (and
> only focus
> > is
> > > > > > > > > by which SRS implementation will be
> simplified in terms
> > of
> > > > > > > > aggregation
> > > > > > > >
> > > > > > > > > maintenance.
> > > > > > > > >
> > > > > > > > > Thanks
> > > > > > > > > Partha
> > > > > > > > >
> > > > > > > > > object, when sending many objects (e.g., at
> the start of
> > a
> > > > > > > > CS or when

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Apr 2011 11:47:56 -0400

My original thinking on this was that you can have a situation where you 
know you have a CS involving sip:foo.com, and you know (somehow) that 
the media coming from foo.com includes contributions from Bob and Carol 
and Ted and Alice. You might not even have signaling URIs for them, and 
you may not be able to distinguish which media is from which person, but 
it still seems like it would be good to have a way to represent what 
*is* known.

But I'm ok with what what is now being discussed if that seems to meet 
people's needs.

	Thanks,
	Paul

On 4/15/2011 11:26 AM, Elwell, John wrote:
>>>>>>>> Media Stream);<Partha>  agreed</Partha>
>>>>>>>> decision whether to remove the last case</Partha>
>>>>>>>>
>>>>>>>> involved as part of CS.</Partha>   Why would we
>>>> create a new RS
>>>>>>>> for such a participant?
>>>>>>>> question whether this corner has to be solved ?</Partha>
>>>>>>>>
>>>>>>>> John (as individual)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Partha
>>>>>>>>>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 15 Apr 2011 22:23:58 +0530

Hi John, Please see inline

> Sent: Friday, April 15, 2011 8:57 PM
> To: Ram Mohan R (rmohanr); Parthasarathi R (partr); [email-masked]
> [JRE] We could treat them as other Participants, but if we don't have
> information about the media they are sending receiving and therefore
> all media is seen by the SRC as being sent/received by the conference
> UA, then I don't really see it makes sense to treat them as separate
> Participant objects.

Yes I agree with you. My thought here is for cases where the conference
UA can learn the other participants, we can convey them as separate
participant objects in the model, of course all of them will be
associated ("sends" association) with the same mixed stream.
For cases where conference UA cannot determine, we will have only one
participant object  ( i.e. conference UA) conveyed in the model

I hope this would be sufficient for most use cases.

> [JRE] I don't think this distinction is particularly relevant to what
> gets sent to the SRS, stored, and subsequently played back. The
> information that really needs to be captured is which participants
> send/receive which media, and signalling. Signalling is just part of
> the CS mechanism that has no relevance to what gets recorded and
played
> back. I don't see why a 3PCC controller would be considered a
> Participant.

I am ok to NOT have this distinction. If there is anyone who sees a need
for this/have a use case that needs this distinction we can consider
otherwise we can ignore this aspect.

Regards,
Ram

> > > with UA, those multiple participants from focus shall be
> represented
> > as
> > > > Subject: [siprec] FW: Do we need to model participants not part
> of
> > CS
> > > > butassociated with Media Stream block in the metadata model ?
> (was
> > > RE:
> > > > Subject: [siprec] Do we need to model participants not part of
CS
> > > > thread to close this issue. I would request people to give
inputs
> > > > media from other participants that are not part of CS. Please
> note
> > > SRC
> > > > Don't model the participants that does not contribute signaling
> in
> > CS
> > > > > > > For example, if these "participants" are not considered
> part
> > of
> > > > the
> > > > > > > > > required to be unique across multiple CS) and so,
> xml:id
> > or
> > > > > > > > enhancing
> [mailto:[email-masked]]
> > > > > > > > > > To: Paul Kyzivat (pkyzivat); [email-masked];
Elwell,
> > > > > > > > > > Adding to Paul's point, I wish to give more
> background
> > > and
> > > > > > > > > reason for
> > > > > > > > > > not end up with unique value always. Our analysis
for
> > URN
> > > > > > > > UUID for
> > > > > > > > > > each level is as follows and please provide your
> input
> > in
> > > > > case
> > > > > > id
> > > > > > > > > > shall be
> > > > > > > > > > tweaked:
> > > > > > > > > >
> > > > > > > > > > and my understanding of his major concern is that
how
> > SRS
> > > > > > > > > > The UUID URN is a pretty inefficient encoding. A
UUID
> > can
> > > > > > > > > > concerned the mechanism for performing partial
> updates
> > > and
> > > > > > > > > the use of
> > > > > > > > > > would be necessary to include the top level
> identifier
> > as
> > > > > > > > > well as one

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 15 Apr 2011 12:38:29 -0700

I do not see a need to distinguish participant "types". Whether or not a
3pcc participant is considered a participant is, I think, an
implementation preference. If the SRS knows something is a 3pcc, it
might choose to not tell the SRS about it. But then again, it may not
know, so it may well the SRS in that case. Also, a participant my
initially not send an media, and my start sending media later, or vice
versa. I think this is all fine and should not require any modification
of the participant information conveyed by the SRS to the SRS.

Cheers,
Charles

Behalf Of Elwell, John
> Sent: Friday, April 15, 2011 8:27 AM
ofCS butassociated with Media
> Stream block in the metadatamodel ? (was RE: Partial updates and
identifiers)
> [JRE] We could treat them as other Participants, but if we don't have
information about the media they
> are sending receiving and therefore all media is seen by the SRC as
being sent/received by the
> conference UA, then I don't really see it makes sense to treat them as
separate Participant objects.
> [JRE] I don't think this distinction is particularly relevant to what
gets sent to the SRS, stored,
> and subsequently played back. The information that really needs to be
captured is which participants
> send/receive which media, and signalling. Signalling is just part of
the CS mechanism that has no
> relevance to what gets recorded and played back. I don't see why a
3PCC controller would be considered
> a Participant.
represented
of
(was
CS
inputs
note
in
part
xml:id
[mailto:[email-masked]]
Elwell,
background
for
input
how
UUID
updates
identifier

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 18 Apr 2011 08:46:25 +0200

> Sent: 15 April 2011 17:54
> To: Elwell, John; Parthasarathi R (partr); [email-masked]
> > > Or is it sufficient if we just treat them as any other 
> participants
> > of
> > > CS.
[JRE] But in this case, even though the UA has learned the identities of other parties behind the conference focus, it doesn't know which of these parties are really contributing to media received by the UA and which of these parties actually receive media sent by the UA. Also the UA does not know what media is exchanged between those other parties. Therefore treating them as Participants is, I think, misleading. I agree we should try to include the identities of these other parties, but it seems to make more sense to include them as attributes of the Participant representing the conference.

John (as individual)

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 18 Apr 2011 08:49:26 +0200

> Sent: 15 April 2011 16:48
> To: [email-masked]
> Subject: Re: [siprec] FW: Do we need to model participants 
[JRE] Exactly, but this can be achieved by including the identities of these parties (e.g., URIs, if known) as attributes of the Participant representing the conference. I think it would be misleading to treat them as Participants, since so little is known about them.

John

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 18 Apr 2011 12:28:35 +0530

Thanks Charles for your feedback. Since there is no need to distinguish
participant types, I will not add anything for that in the model/format

Regards,
Ram

> From: Charles Eckel (eckelcu)
> Sent: Saturday, April 16, 2011 1:08 AM
> To: Elwell, John; Ram Mohan R (rmohanr); Parthasarathi R (partr);
> [email-masked]
> I do not see a need to distinguish participant "types". Whether or not
> a 3pcc participant is considered a participant is, I think, an
participants
> > conference UA, then I don't really see it makes sense to treat them
> as separate Participant objects.
> >
> > >
> > > > associated with dialogs but instead it represents session with
> the
> > > list
> > > > 1. Conferences. I think depending what view the SRC has of the
> CS,
> > > > there are two situations:
> > > >
> > > > (a) The SRC sees all parties in the conference and has
visibility
> of
> > > > what Media Streams each party sends and receives. In this case,
I
> > > think
part
> > > > > Please continue the other issues in original thread and lets
> use
> > > this
> > > > > We(Authors of Metadata model) included participants that are
> not
> > > part
> > > > > of CS to imply:
> > > > > without   having a reported signaling relationship to it. E.g
> is
> > > > given
> > > > > here by Henry Lum
> > > > > > I think the attached message was the last in that thread. So
> I
> > > > don't
> > > > > > > > > <Partha> Sorry, I mixed up my statement with the
latest
> > > > update
> > > > > > > > > [JRE] I don't understand the words "Because CS may
span
> > > > > > > > > to be grouped together in RS1, RS2 by some means
> through
> > > > given
> > > > > > > > > metadata.
> > > > > > > The
> > > > > > > > > > > some relevant natural id for the rest of the
> element
> > > will
> > > > > > > > > serve the
> > > > > > > > > > > purpose.
> > > > > > > > > > > the purpose with session unique id. Here as well,
> We
> > > > shall
> > > > > > > > > > discuss and
> > > > > > > > > >
> > > > > > > > > > > fine tune if required.
> > > > > > > > > > >
> > > > > > > > > > > There is no dependency on the particular form of
> the
> > > URI,
> > > > > but
> > > > > > > > > > > specifying they must be UUID URNs makes it
possible
> to
> > > > > > > > > > > in 32 bits, so we could consider retaining UUIDs
> but
> > > > alter
> > > > > > the
> > > > > > > > > > > changed. So, for example, in a large conference,
it
> > > would
> > > > > > > > > > > time. Although this might be efficient for
updating
> an
> > > > > > > > > > > identifiers for other objects. Thus when updating
a

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 18 Apr 2011 12:55:31 +0530

Hi John,

Please see inline  [Ram]

> Sent: Monday, April 18, 2011 12:16 PM
> ofCS butassociated with Media Stream block in the metadatamodel ?
> 
> 
> 
> [JRE] But in this case, even though the UA has learned the identities
> of other parties behind the conference focus, it doesn't know which of
> these parties are really contributing to media received by the UA and
> which of these parties actually receive media sent by the UA. Also the
> UA does not know what media is exchanged between those other parties.

[Ram] This is a good point that you have brought up. 
The conference event package (RFC 4575) does have a enough information
to convey the above details.
The conf package has certain elements (<endpoint>) defined for each user
(<user>). This element (<endpoint>) does convey the information on the
state(through <status> element) of each user of the conference. This has
values connected/on-hold among others. On-hold is used to indicate that
user is neither "hearing" the conference mix nor is his/her media being
mixed in the conference. Please refer to section 5.7.3 of RFC 4575 for
more details.
Also the information on what media is exchanged in the conference is
conveyed in <available-media> element.

However I see its going to be very difficult for the Conference UA/SRC
to retrieve this information each time it has to send metadata to SRS.

So I am open to your suggestion of just having basic information (like
URI) about participant behind conference UA participant.
I would like to hear thoughts from others like Charles, Brian and others
who are interested in conference recording in SIPREC.

Regards,
Ram

> Therefore treating them as Participants is, I think, misleading. I
> agree we should try to include the identities of these other parties,
> but it seems to make more sense to include them as attributes of the
> Participant representing the conference.
> 
> John (as individual)

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Apr 2011 08:38:46 -0400

I am ok with either direction here, as long as its done in a way that 
makes clear what is/isn't known. The point here is that there is some 
information about participation that we would like to retain, whether we 
have details of association with particular media streams or not.

In the future, you might want to search for recorded CSs that involve a 
particular participant. We should be enabling that even in this case.

	Thanks,
	Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 18 Apr 2011 18:16:59 +0530

Paul,

Agreed with your thoughts. The information that John asks for can be
learnt from conf package as I mentioned in the other mail.
http://www.ietf.org/mail-archive/web/siprec/current/msg01861.html

However I am ok with either directions once we have a consensus from
wider team.

Regards,
Ram

> Behalf Of Paul Kyzivat (pkyzivat)
> Sent: Monday, April 18, 2011 6:09 PM
> To: [email-masked]

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 18 Apr 2011 18:55:08 +0530

I prefer to represent as a separate participant because it is possible
to fetch participant information using RFC 4575. As I explained with
model diagram in another mail thread, I'm seeing conference participants
to media stream as remote mixed stream relationship. In case of mixed
stream, it is always expected to lose lot of information like time at
which specific participant contributes to the media and remote mixed
stream is not the exception.

Having said that I don't have experience in RFC 4575 implementation, it
looks bit complicated to pull these participant data in the real time
but those implemented may talk for it.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ram Mohan R (rmohanr)
Sent: Monday, April 18, 2011 6:17 PM
To: Paul Kyzivat (pkyzivat); [email-masked]
Subject: Re: [siprec] FW: Do we need to model participants not part
ofCSbutassociated with Media Stream block in the metadatamodel ?

Paul,

Regards,
Ram

> information about participation that we would like to retain, whether 
> we have details of association with particular media streams or not.
> 
> >> Yes I agree with you. My thought here is for cases where the 
> >> conference UA can learn the other participants, we can convey them 
> >> as separate participant objects in the model, of course all of them

> >> will be associated ("sends" association) with the same mixed 
> >> stream.