Subject: [siprec] Issue with participant scoping in the current model and its implication on association attr representation

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 27 Oct 2011 23:16:55 +0530

(Sorry for lengthy e-mail)

This is a follow up to the mail thread
http://www.ietf.org/mail-archive/web/siprec/current/msg02810.html

In the last IETF meeting there was a consensus that a participant can
have a life outside of CS. 

However the current model scopes participant to always a session.
Should we have to change the model to have participant outside scope of
session ? I think it may not make sense to model participants under RS
as these are participants of Session. The only use case where we can
have a participant in a RS with no CS is for Persistent recording
sessions (e.g. setup from agent phone(SRC) to SRS) This RS will be setup
even without any CS.  If an SRC for this case sends a snapshot before a
CS starts it may have participant information without any session. 
Does the WG sees a value in such a use case or should we retain the
model as is ?

The current model (ver 04) also impacts the way association attributes
are represented. Since the current draft (ver-04)the metadata model
scopes participant and stream elements to session the schema also was
designed the same way. The <participant> and <stream> attributes are
scoped/associated to a session (see section 7.1 example). IOW the
association attributes of <participant> to <session> are already
represented.

Now if we have to go with approach 2 for representing association
attributes, we will have to do one of the two ways:

If we stick the current model/schema:
-----------------------------------
We will have represent in the following way. Note this is a mix of
approach 1 (existing representation which acheives participant session
association) and approach 2 ( for part-stream association).  The issue
with this approach is if the same participant is simultaneously in
multiple sessions( cases like participant goes on hold on one line and
talks to another participant) and SRC sends a snapshot then we will have
multiple <participant> elements each having different session IDs. 
        <participant
           id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"
           session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> 
                 <aor>sip:[email-masked]</aor>
                 <associate-time>2010-12-16T23:41:07Z</associate-time>
                 <capabilities> XXX</capabilties>
         </participant>

And for participant-stream you will have a new element 

<participantStreamAssoc
 participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"
 stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a ">
    <associate-time>2010-12-16T23:41:07Z</associate-time>
    <csrc>contributing SSRC-1</csrc>   
</participantStreamAssoc>

If we change the model to remove the scoping of participant/stream to
session:
------------------------------------------------------------------------
-----

<participant
           id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> 
           <aor>sip:[email-masked]</aor> 
</participant>

<participantSessAssoc
         participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"
           session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"
               <associate-time>2010-12-16T23:41:07Z</associate-time>
               <capabilities> XXX</capabilties> 
</participantSessAssoc>

<participantStreamAssoc
 participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"
 stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a ">
    <associate-time>2010-12-16T23:41:07Z</associate-time>
    <csrc>contributing SSRC-1</csrc>   
</participantStreamAssoc>

Let me know your comments.

Regards,
Ram

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Oct 2011 17:12:00 -0400

> However the current model scopes participant to always a session.

I don't think that is quite right. The *model* requires that each 
participant be associated with one or more sessions. It doesn't scope to 
a single session.

> Does the WG sees a value in such a use case or should we retain the

IMO the change we would be talking about is that a participant can be 
associated with *zero* or more sessions, rather than one or more.

In addition to the use case Ram mentions above, this would help with the 
mapping to xml. If we go with participantSessAssoc (as mentioned below) 
it becomes *possible* to define a participant with no associations to 
sessions. Allowing the same in the model at least makes them consistent.

	Thanks,
	Paul

> designed the same way. The<participant>  and<stream>  attributes are
> association attributes of<participant>  to<session>  are already
> represented.
>
> multiple<participant>  elements each having different session IDs.
>          <participant
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 28 Oct 2011 10:24:26 +0530

To add to Paul, with the proposed change, the model will look as below

  +-------------------------------+
  |   Communication Session (CS)  |
  |                               |
  +-------------------------------+
        | 0..*                 |1..*              
        | ^^^^^^^^             |                 
        | 2..*                 |0..*              
  +-------------+ receives +----------------+     
  | Participant |----------|  Media Streams |
  |             |0..*  0..*|                | 
  |             |          |                |
  |             |          |                |
  |             |  sends   |                |
  |             |----------|                |
  |             |1.*   0..*|                |
  +-------------+          +----------------+

A participant can be associated with zero or more sessions.

And with the above model we can have an approach to define a participant
with no associations to sessions and have XML elements separate (like
<participantSessAssoc>) for association classes as in approach 2
mentioned below

Ram

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: Friday, October 28, 2011 2:42 AM
> To: [email-masked]
> Subject: Re: [siprec] Issue with participant scoping in the current
> model and its implication on association attr representation
> 
> > even without any CS.  If an SRC for this case sends a snapshot
before
> a
---------------------------------------------------------------------
> ---

---

From: "John Elwell" <[email-masked]>
Date: Fri, 28 Oct 2011 09:07:12 +0100

A participant has various identification attributes (aor, name) that can be 
derived from different SIP header fields. So how does the SRC determine that 
two participants from different CSs are really the same participant? For 
example, they might have the same SIP URI but different display names, or in 
one case there might only be the From header field but in the other case 
there might also be the PAI header field. If the idea is to dump all the 
information we know about a participant (from the SIP signalling on the CS 
concerned), into the <participant/> element, it seems to me the 
<participant/> element really should be tied to a single CS. Any attempt to 
do otherwise is likely to lead to inconsistent results.

John

----- Original Message ----- 
From: "Ram Mohan R (rmohanr)" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, October 27, 2011 6:46 PM
Subject: [siprec] Issue with participant scoping in the current model andits 
implication on association attr representation

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Fri, 28 Oct 2011 14:39:47 +0530

<Sorry for the lengthy mail. IMO, This discussion is one of the major
 change in metadata>

I'm interested in knowing whether folks are interested in handling 
participant, stream completely outside the scope of session. 
In fact, we discussed this requirement as part of metadata model 
discussion and come to the conclusion not to include. In case
participant, stream are outside the scope of session, the following 
recording metadata from SRC is valid:

<recording xmlns='urn:ietf:params:xml:ns:recording'>
          <dataMode>full</dataMode>
          <participant
             id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3">
              <aor>sip:[email-masked]</aor>
             <send>urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a</send>
           </participant>
          <stream id="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a">
              <label>96</label>
          </stream>
          <stream id="urn:uuid:01c47915-4777-11d8-bc70-0090272ff725">
              <label>97</label>
          </stream>
</recording>

Also, in the later partial update, session shall be added and associate 
with the above participant & stream element.

Here, SRS has to maintain participant, stream unique id as a separate
flat
Data (no hierarchy). Only issue is that SRS has to maintain flat
database for
Each of these elements.

The current -04 draft is based on the assumption that participant and 
stream are within a session and it is possible for participant & stream 
to move across multiple sessions using unique id. The rationale of the 
current draft approach is that commonly used callflow metadata is simple

whereas specific corner case callflow like same participant in multiple 
session will have complex mechanism.

In case we see the strong usecases for going for independent stream,
Participants which is outside the session, we will go for it.

Thanks
Partha

>From: [email-masked] [mailto:[email-masked]] On
Behalf
>Of Ram Mohan R (rmohanr)
>Sent: Friday, October 28, 2011 10:24 AM
>To: Paul Kyzivat; [email-masked]
>modeland its implication on association attr representation
>
>> > Should we have to change the model to have participant outside
scope
>> of

---

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

Hello John,

The change we are discussing to the model is only for participant. A
stream will still be associated with 1 or more session. Only for
participant we want to make it associate Zero or more sessions.

The zero is to give the flexibility to represent the XML in the
following way:

<participant

<participantSessAssoc

<participantStreamAssoc

In practice there will be very few use-cases where a participant will be
zero session. I had given one example below.
The main intent to change the model is to keep it inconsistent with XML
(approach 2 above)

In case we wish not to change to model (as it may creep in some corner
cases), we will have to go with a mix of approach1+2 as I outlined below
( first example).

Is this ok with the WG ?

Regards,
Ram

> From: John Elwell [mailto:[email-masked]]
> Sent: Friday, October 28, 2011 1:37 PM
> To: Ram Mohan R (rmohanr); [email-masked]
> model andits implication on association attr representation
> 
> derived from different SIP header fields. So how does the SRC
determine
> that
> information we know about a participant (from the SIP signalling on
the
> CS
before

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Oct 2011 09:35:21 -0400

On 10/28/11 4:07 AM, John Elwell wrote:
> A participant has various identification attributes (aor, name) that can
> be derived from different SIP header fields. So how does the SRC
> determine that two participants from different CSs are really the same
> participant? For example, they might have the same SIP URI but different
> display names, or in one case there might only be the From header field
> but in the other case there might also be the PAI header field. If the
> idea is to dump all the information we know about a participant (from
> the SIP signalling on the CS concerned), into the <participant/>
> element, it seems to me the <participant/> element really should be tied
> to a single CS. Any attempt to do otherwise is likely to lead to
> inconsistent results.

I think we can leave this decision up to the SRC. It can have a variety 
of ways to determine equivalence of participants in differing CSs. 
Depending on how it gets into calls it might have special knowledge. It 
might do so based on Contact address, or by being collocated with the 
UA. It can clearly know this for a single dialog as it evolves.

In the worst case, it *doesn't* recognize that two participants are the 
same, and so assigns them distinct IDs. This doesn't preclude the SRS 
from doing analysis on the names/aors of distinct participants and 
deciding by policy to consider them equivalent.

	Thanks,
	Paul

> John
>
>
> ----- Original Message ----- From: "Ram Mohan R (rmohanr)"
> <[email-masked]>
> To: <[email-masked]>
> Subject: [siprec] Issue with participant scoping in the current model
> andits implication on association attr representation
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Oct 2011 10:15:05 -0400

This proposes an additional change, to remove the subordination of 
stream to session. IMO this should be considered separately from 
participant, as the arguments are different.

AFAICT, the use case Partha gives below is the only one that calls for 
stream independent of session. And I'm not sure of the need for this. 
ISTM the only reason to do this is to really record streams from 
participants when there is no session.

This might allow capturing media earlier during call setup, by defining 
the streams early, and associating them with participants and sessions 
when that becomes known. *If* an SRS can figure out how to take 
advantage of that.

	Thanks,
	Paul

On 10/28/11 5:09 AM, Ravindran Parthasarathi wrote:
> with the above participant&  stream element.
>
> stream are within a session and it is possible for participant&  stream

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 28 Oct 2011 21:27:17 +0530

I don't see a strong use case to have session associate to zero
sessions. IMO we can retain the session associations as it is in the
current model.

Now coming to participant, the main reason why I am inclined to change
the association is to have consistency with XML  if we adopt approach 2.

Regards,
Ram

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, October 28, 2011 7:45 PM
> To: Ravindran Parthasarathi
> Cc: Ram Mohan R (rmohanr); [email-masked]
> Subject: Re: participant & stream outside the scope of session
> 
> >>> participant be associated with one or more sessions. It doesn't
> scope
> >>> to
> >>> a single session.
> >>>
> >>>> session ? I think it may not make sense to model participants
> under
> >>> RS
> >>>> sessions (e.g. setup from agent phone(SRC) to SRS) This RS will
be
> >>> setup
> >>> In addition to the use case Ram mentions above, this would help
> with
> >>> the
> >>>> designed the same way. The<participant>   and<stream>
attributes
> > are
> >>>> multiple sessions( cases like participant goes on hold on one
line
> >>> and
> >>>> talks to another participant) and SRC sends a snapshot then we
> will
> >>> have
> >>>>                    <associate-time>2010-12-
> 16T23:41:07Z</associate-
> >>> time>
> >>>> If we change the model to remove the scoping of
participant/stream
> >> to
--------------------------------------------------------------------
> -

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 28 Oct 2011 21:39:12 +0530

A typo in the below email. Sorry for that. I meant

"
 I don't see a strong use case to have stream associate to zero
sessions. IMO we can retain the stream associations
                                        ^^^^^^
^^^^
 as it is in the current model."

Thanks,
Ram                         

> Behalf Of Ram Mohan R (rmohanr)
> Sent: Friday, October 28, 2011 9:27 PM
> To: Paul Kyzivat; Ravindran Parthasarathi
> Cc: [email-masked]
> Subject: Re: [siprec] participant & stream outside the scope of
session
> > >>>> In the last IETF meeting there was a consensus that a
> participant
> > >> can
> > >>>> as these are participants of Session. The only use case where
we
> > > can
> > >>> IMO the change we would be talking about is that a participant
> can
> > be
> > >>> it becomes *possible* to define a participant with no
> associations
> > to
> > >>>> scopes participant and stream elements to session the schema
> also
> > >> was
> > >>>> association) and approach 2 ( for part-stream association).
The
> > >>> issue

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Fri, 28 Oct 2011 22:48:40 +0530

Hi Ram,

As Paul mentioned, stream associated with zero session was brought up as
part of the persistent connection from the endpoint discussion and it
was pushed back because stream & participant has to be within session
(CS). I'm worried that participant to zero session change may re-open
the earlier closure and call for one more discussion. 

Also, the current syntax of stream is associated with session closely
which has to be changed consistently in case participant is changed its
association representation with session.

      <stream id="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a"
              session="urn:uuid:cd27cfa1-2bdd-4830-a653-70374d10f103">
              <label>98</label>
          </stream>

It will be good in case we get the feedback on these aspect.

Thanks
Partha

>From: Ram Mohan R (rmohanr) [mailto:[email-masked]]
>Sent: Friday, October 28, 2011 9:39 PM
>To: Ram Mohan R (rmohanr); Paul Kyzivat; Ravindran Parthasarathi
>Cc: [email-masked]
>Subject: RE: [siprec] participant & stream outside the scope of session
>
>> > > to move across multiple sessions using unique id. The rationale
of
>> > >>>> Does the WG sees a value in such a use case or should we
retain
>> > >>> mapping to xml. If we go with participantSessAssoc (as
mentioned
>> > >> below)
>> > >>>> We will have represent in the following way. Note this is a
mix
>> > >>>> with this approach is if the same participant is
simultaneously
>> in

---

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

Hi Partha,

Please see inline

> From: Ravindran Parthasarathi [mailto:[email-masked]]
> Sent: Friday, October 28, 2011 10:49 PM
> To: Ram Mohan R (rmohanr); Paul Kyzivat
> Cc: [email-masked]

I don't see a need for the above. We are changing the participant
association to session to allow it to be consistent with XML if we
choose approach 2.
Even in approach 2, stream has to be associated with a session and so
there is no need to change that association.

Regards,
Ram

> >> the association is to have consistency with XML  if we adopt
> approach
> >> 2.
> >>
> >> Regards,
> >> Ram
> >>
> >> > AFAICT, the use case Partha gives below is the only one that
calls
> >> for
> >> > > The current -04 draft is based on the assumption that
> participant
> >> and
> >> > > current draft approach is that commonly used callflow metadata
> is
> >> > simple
> >> > >
> >> > >> To add to Paul, with the proposed change, the model will look
> as
> >> > below
> >> > >>
> >> > >> with no associations to sessions and have XML elements
separate
> >> > (like
> >> > >>> From: [email-masked]
[mailto:[email-masked]]
> >On
> >> > >>>> are represented. Since the current draft (ver-04)the
metadata
> >> > model
> >> > >>>> scoped/associated to a session (see section 7.1 example).
IOW
> >> > >>>> approach 1 (existing representation which acheives
> participant
> >> > >>> session
> >> > >>>> multiple<participant>   elements each having different
> session
> >> > IDs.
> >> > >>>>           <participant
> >> > >>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Oct 2011 14:01:25 -0400

+1 to Ram's response.

As I noted before, if you want to reopen question of allowing stream 
without session, I think that should be discussed separately.

	Thanks,
	Paul

On 10/28/11 1:27 PM, Ram Mohan R (rmohanr) wrote:
>> Subject: RE: [siprec] participant&  stream outside the scope of
> session
>>
>> Hi Ram,
>>
>> was pushed back because stream&  participant has to be within session
>>> Subject: RE: [siprec] participant&  stream outside the scope of
>> session
>>>
>>>> Subject: Re: [siprec] participant&  stream outside the scope of
>>> session
>>>>
>>>>> Subject: Re: participant&  stream outside the scope of session
>>>>>

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Sat, 29 Oct 2011 01:19:00 +0530

Paul/Ram,

Now, participant and stream are associated with session as an
aggregation. In case participant is possible to be represented outside
session, it is very much possible for stream to be outside the session
as shown in persistent usecase. In case of persistent usecase, RS stream
is created in advance to avoid the earlier clipping, the session will be
associated in metadata whenever the session is established, session will
be terminated without removing RS stream

In case new participant session associated XML element is added, it is
possible to have stream session associated XML element as well
separately.

Including Leon in this mail thread as he asked for persistent usecase.
I'm reopening this usecase because let us close the related issue at the
same time.

Thanks
Partha

>Sent: Friday, October 28, 2011 11:31 PM
>To: Ram Mohan R (rmohanr)
>Cc: Ravindran Parthasarathi; [email-masked]
>Subject: Re: [siprec] participant & stream outside the scope of session
>
>+1 to Ram's response.
>
>>> As Paul mentioned, stream associated with zero session was brought
up

---

From: Brad Winslow <[email-masked]>
Date: Mon, 31 Oct 2011 20:26:35 +0000

Hi Folks,

Perhaps I'm missing something about the Participant/Session association, and perhaps some of this applies to the stream/session association as well.

The current metadata draft has two attributes for the participant, the "id" and the "session" both expressed as UUIDs.  The "id" field seems to be a unique identifier the SRC could use to indicate the uniqueness of this participant in multiple CSs assuming the SRC has the ability to determine if the participant is the same between CSs.  The SRS cold use this field to identify participants across sessions.  The same holds true of the 'id' field in the stream element, if we assume a particular 'id' is a MOH stream, it's id could be consistent across CSs.  IMO we are under-utilizing the 'id' attribute for participant and stream identity.  In the case where the SRC cannot determine if the unique identity of the participant, it would simply create a new UUID for the participant when it enters into a new CS.

Much of the information in the new ParticipantSessionAssoc element could be contained in the participant element. perhaps I don't understand the use-cases where the association element reduces the complexity of the metadata well enough. Additional xs:any elements could be passed between SRC and SRS to help identify the participants however this would quickly lead to interoperability problems between vendors.

Thanks,
Brad

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ravindran Parthasarathi
Sent: Friday, October 28, 2011 3:49 PM
To: Paul Kyzivat; Ram Mohan R (rmohanr); Leon Portman
Cc: [email-masked]
Subject: Re: [siprec] participant & stream outside the scope of session

Paul/Ram,

Now, participant and stream are associated with session as an aggregation. In case participant is possible to be represented outside session, it is very much possible for stream to be outside the session as shown in persistent usecase. In case of persistent usecase, RS stream is created in advance to avoid the earlier clipping, the session will be associated in metadata whenever the session is established, session will be terminated without removing RS stream

In case new participant session associated XML element is added, it is possible to have stream session associated XML element as well separately.

Including Leon in this mail thread as he asked for persistent usecase.
I'm reopening this usecase because let us close the related issue at the same time.

Thanks
Partha

up
>>>>                                         ^^^^^^ ^^^^ as it is in the 
>>>> current model."
>>>>
>>>> Thanks,
>>>> Ram
>>>>
>>>>
>>>>>>>>>>               <aor>sip:[email-masked]</aor> </participant>
>>>>>>>>>>
>>>>>>>>>> <participantSessAssoc
>>>>>>>>>>