Subject: Re: [siprec] participant & stream outside the scope of session

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Nov 2011 11:24:58 -0400

On 10/31/11 4:26 PM, Brad Winslow wrote:
> 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.

That is intended.

> 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.

Yes.

> IMO we are under-utilizing the 'id' attribute for participant and stream identity.

I'm happy to have suggestions of how to do things better.

> 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.

Again, that is the intent.
If a newly discovered participant cannot be determined to be "the same" 
as a previously identified participant, then it is treated as a new one.

Note that an identical "From" field is not sufficient info to consider 
this participant the same as some other participant.

> 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.

The intent is that the ParticipantSessionAssoc carries information that 
is specific to the involvement of the participant in a particular 
session, while the Participant element carries the information that 
describes the participant independent of the session or stream it is 
involved in.

Which information do you think could be moved?

	Thanks,
	Paul

> 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
>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[email-masked]]
>> 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 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:
>>> Hi Partha,
>>>
>>> Please see inline
>>>
>>>> -----Original Message-----
>>>> From: Ravindran Parthasarathi [mailto:[email-masked]]
>>>> Sent: Friday, October 28, 2011 10:49 PM
>>>> To: Ram Mohan R (rmohanr); Paul Kyzivat
>>>> Cc: [email-masked]
>>>> Subject: RE: [siprec] participant&   stream outside the scope of
>>> session
>>>>
>>>> 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.
>>>
>>> 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
>>>
>>>>
>>>>         <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
>>>>
>>>>> -----Original Message-----
>>>>> 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
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>> 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
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> 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
>>>>>>>
>>>>>>> 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:
>>>>>>>> <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
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> 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]
>>>>>>>>> Subject: Re: [siprec] Issue with participant scoping in the
>>>>>> current
>>>>>>>>> modeland its implication on association attr representation
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>> On 10/27/11 1:46 PM, Ram Mohan R (rmohanr) wrote:
>>>>>>>>>>> (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.
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>>> 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 ?
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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
>>>
>
> _______________________________________________
> 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: Ravindran Parthasarathi <[email-masked]>
Date: Tue, 1 Nov 2011 18:05:58 +0000

Paul/Brad,

Please read inline.

Thanks
Partha

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Paul Kyzivat
>Sent: Tuesday, November 01, 2011 8:55 PM
>To: [email-masked]
>Subject: Re: [siprec] participant & stream outside the scope of session
>
>> 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.
>
>That is intended.
>
>> 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.
>
>Yes.
>
>> 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.
>
<partha> Agree with Paul till this point </partha>

>
>> 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.
>
<partha> Infact, participant XML element with session id (current XML form) 
includes participant and participantsessionassoc. The reason for this design 
is to make partial update of metadata element or else we would have easily
end-up in simple hierarchical metadata. Now the question is whether 
separating participant XML element and participantSessionAssoc element is 
going to make much difference in the partial update? IMO, participantSessionAssoc
change is limited compare to participant change itself. We have 4 element
within participant (1 for participant + 3 for participantsessioAssoc). The partial
update for 1 element in participant does not make much different.

The same argument applies for streamSessionAssoc as well. </partha>

>Behalf Of Ravindran Parthasarathi
>> 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.
>>