Subject: [siprec] Can an MS object span several CSs in a CSG?

From: "Elwell, John" <[email-masked]>
Date: Tue, 24 May 2011 09:36:21 +0200

We seem to have consensus that a Media Stream object represents a recorded media stream, contributed to by one, several or all Participants. However, Partha also wrote:

"2) Each MS lifetime related to CSG because participant may move from one
CS to another CS within single CSG and also CSG will span across
multiple RS."

I am not sure we had resolved this during earlier discussions on the scope of an MS object. Although the same Participant can participate in several CSs within the same CSG, I don't think the recorded media streams need to be considered the same. Any other views?

John (as individual)

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 24 May 2011 16:56:15 +0530

John,

I agree that it is not mandatory to consider recorded stream of a
specific participant in several CS within the same CSG as one recorded
stream but SIPREC protocol design MUST NOT restrict a SRC in case it
wishes to design in such a way.

Thanks
Partha 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Elwell, John
Sent: Tuesday, May 24, 2011 1:06 PM
To: [email-masked]
Subject: [siprec] Can an MS object span several CSs in a CSG?

We seem to have consensus that a Media Stream object represents a
recorded media stream, contributed to by one, several or all
Participants. However, Partha also wrote:

"2) Each MS lifetime related to CSG because participant may move from
one CS to another CS within single CSG and also CSG will span across
multiple RS."

I am not sure we had resolved this during earlier discussions on the
scope of an MS object. Although the same Participant can participate in
several CSs within the same CSG, I don't think the recorded media
streams need to be considered the same. Any other views?

John (as individual)
_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

---

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

Hi Partha,

Is an example of this the same music on hold audio stream existing as
the same MS within multiple CSs? If so, then I understand your
requirement to be that the SRC be able to indicate multiple instances of
this audio stream within several CSs as being the same MS. Is that
correct?

Thanks,
Charles

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Parthasarathi R (partr)
> Sent: Tuesday, May 24, 2011 4:26 AM
> To: Elwell, John; [email-masked]
> Subject: Re: [siprec] Can an MS object span several CSs in a CSG?
> 
> John,
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 24 May 2011 22:06:01 +0530

Charles,

I did bring about this specific usecase of MMOH/MOH stream being played
to different participants earlier and suggested that they have to
treated as a same MS across multiple CSs (potentially recorded using
multiple RSs).
Refer http://www.ietf.org/mail-archive/web/siprec/current/msg01886.html

We had several discussions on it and it and several folks were in favor
of treating it as separate MS as there would be complexity in DB design.

Regards,
Ram

> Behalf Of Charles Eckel (eckelcu)
> Sent: Tuesday, May 24, 2011 9:11 PM
> To: Parthasarathi R (partr); Elwell, John; [email-masked]
> Behalf

---

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

Hi Ram,

I think that is many cases, they will be treated as separate MSs due to
the complexities you mention. However, I am trying to understand if
Partha feels allowing an SRC to treat them as a single MS is still
required. If not, then what is a use case? A concrete example would help
me, and potentially others, to better understand the motivation behind
Partha's requirement for modeling media from multiple CSs as a single
MS.

Cheers,
Charles

> From: Ram Mohan R (rmohanr)
> Sent: Tuesday, May 24, 2011 9:36 AM
> To: Charles Eckel (eckelcu); Parthasarathi R (partr); Elwell, John;
[email-masked]
> Subject: RE: [siprec] Can an MS object span several CSs in a CSG?
> 
> Charles,
> 
> I did bring about this specific usecase of MMOH/MOH stream being
played to different participants
> earlier and suggested that they have to treated as a same MS across
multiple CSs (potentially recorded
> using multiple RSs).
> Refer
http://www.ietf.org/mail-archive/web/siprec/current/msg01886.html
> 
> We had several discussions on it and it and several folks were in
favor of treating it as separate MS
> as there would be complexity in DB design.
> 
> Regards,
> Ram
> 
> 
> > requirement to be that the SRC be able to indicate multiple
instances
> > of
> > > scope of an MS object. Although the same Participant can
participate
> > in

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 25 May 2011 03:44:10 +0530

Hi Charles,

One of the usecase in my mind is discussed in
http://www.ietf.org/mail-archive/web/siprec/current/msg01890.html. The
details are as follows:

B2BUA acts as SRC. A, B, C are participants within single B2BUA. A
creates single RS for a CSG.

1) A calls B through B2BUA. B2BUA creates RS towards SRS with CSG1, CS1,
MS1 (A's media stream), MS2 (B's media stream), Participant1 as A &
Participant2 as B.
2) B connects with C through B2BUA
3) B transfer the call of A & B to C using REFER, B2BUA converts REFER
to RE-INVITE towards A & C and A & C are connected. B2BUA updates RS
with CS2, Participant1 as A & participant2 as C, MS1(A's media stream),
MS2(C's media stream). There is no update on RS1, CSG1, MS1, MS2. MS2
will become MS2 with the new association and in terms of format, it will
associate with <send> tag

Thanks
Partha  

-----Original Message-----
From: Charles Eckel (eckelcu) 
Sent: Wednesday, May 25, 2011 1:39 AM
To: Ram Mohan R (rmohanr); Parthasarathi R (partr); 'Elwell, John';
[email-masked]'

Hi Ram,

Cheers,
Charles

> played to different participants earlier and suggested that they have 
> to treated as a same MS across multiple CSs (potentially recorded
using multiple RSs).
> favor of treating it as separate MS as there would be complexity in DB
design.
> > Is an example of this the same music on hold audio stream existing 
> > as the same MS within multiple CSs? If so, then I understand your 
> > instances of this audio stream within several CSs as being the same 
> > MS. Is that correct?
> >
> > Thanks,
> > Charles
> >
> > > stream but SIPREC protocol design MUST NOT restrict a SRC in case 
> > > it wishes to design in such a way.
> > >
> > > Thanks
> > > Partha
> > >
> > > "2) Each MS lifetime related to CSG because participant may move 
> > > from one CS to another CS within single CSG and also CSG will span

> > > across multiple RS."
> > >
> > > I am not sure we had resolved this during earlier discussions on 
> > > the scope of an MS object. Although the same Participant can 
> > > participate
> > in

---

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

> From: Parthasarathi R (partr) [mailto:[email-masked]] 
> Sent: 24 May 2011 23:14
> To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Elwell, 
> John; [email-masked]
[JRE] What harm is done (what do we lose) if, following transfer, A's media stream is called MS3 and C's media stream is called MS4? MS3 can reference the same SDP m-line (through a=label) as MS1, and likewise MS4 could reference the same SDP m-line as MS2, if we are concerned about recycling media descriptions in RS SDP.

John (as individual)

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 25 May 2011 13:17:34 +0530

John,

===================================================================

> with CS2, Participant1 as A & participant2 as C, MS1(A's media 
> stream), MS2(C's media stream). There is no update on RS1, CSG1, MS1, 
> MS2. MS2 will become MS2 with the new association and in terms of 
> format, it will associate with <send> tag
[JRE] What harm is done (what do we lose) if, following transfer, A's
media stream is called MS3 and C's media stream is called MS4? 
=====================================================================
<Partha> To indicate MS1 as MS3, MS1 media block has to be stopped in
the partial-update and start MS3 separate which is not required in case
there is a means to have common MS1. </Partha>

========================================================================
=======================
MS3 can reference the same SDP m-line (through a=label) as MS1, and
likewise MS4 could reference the same SDP m-line as MS2, if we are
concerned about recycling media descriptions in RS SDP.
========================================================================
==================
<Partha> As you mentioned, we will lose recycling of media description
in RS SDP without common value in media stream object for this scenario.
AFAIK, Your proposal needs enhancement in RFC 4574 as label attribute
scope is within single SIP message and not required to be unique in all
SIP messages of a given dialog. </Partha> 

Thanks
Partha

John (as individual)

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 25 May 2011 15:46:41 +0200

> Sent: 25 May 2011 08:48
> To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R 
> (rmohanr); [email-masked]
[JRE] It seems this distorts the model in order to give some minor efficiency improvement during metadata updates. I doubt that this alone is sufficient justification for having the MS persist from one CS to another CS.

[JRE] I don't understand your point. With my proposal we can still recycle RS SDP m-lines.

> SIP messages of a given dialog. </Partha> 
[JRE] But I think we could nail that down as a requirement of the SIPREC protocol.

John (as individual)

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 26 May 2011 20:25:21 +0530

John,

The callflow mentioned by me is the basic primitive in the call center
scenario wherein customer (participant) is same throughout the session
and agents are changed using transfer service and B2BUA acts as SRC.
IMO, it is one of key requirement to be considered in case we support
for partial-update. This may not be the only callflow where MS
partial-update is required in this fashion. During -00 format draft, I
thought that the partial-update is not required but lot of folks raised
the concern that partial update is important. Current, -01 format draft
is designed to support partial-update. Now, You propose to restrict MS
partial-update across CS. IMO, it is a not good idea to restrict in the
protocol level. Anyway, I think that we need others opinion before
conclude here.

Enhancing label attribute across the multiple SIP message to tie between
Metadata XML and RS SDP m-line is possible. SRC has to ensure that label
for the given RS SDP m-line should have same label throughout single CSG
even though it span across multiple CS and multiple RS. Even then, it
will not meet partial-update requirement as mentioned below in this mail
thread. At this moment, I'm favoring URN UUID and not label attribute
enhancement.   

Please read inline

Thanks
Partha

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Wednesday, May 25, 2011 7:17 PM
To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R

> To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R (rmohanr); 
> [email-masked]
> the partial-update and start MS3 separate which is not required in 
> case there is a means to have common MS1. </Partha>
[JRE] It seems this distorts the model in order to give some minor
efficiency improvement during metadata updates. I doubt that this alone
is sufficient justification for having the MS persist from one CS to
another CS.

[JRE] I don't understand your point. With my proposal we can still
recycle RS SDP m-lines.

<Partha> Agreed that Recycle is possible with your proposal. I indicated
the need for unique-id in this  requirement </Partha>

> SIP messages of a given dialog. </Partha> 
[JRE] But I think we could nail that down as a requirement of the SIPREC
protocol.

John (as individual)

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 27 May 2011 11:25:47 +0200

> Sent: 26 May 2011 15:55
> for partial-update. 
[JRE] Agreed the Participant remains the same, but we are discussing MS.

> This may not be the only callflow where MS
[JRE] I am not opposed to partial update, but I would like to avoid distorting the model just to gain some efficiency improvements in certain cases. To me it is not intuitive that a MS on one CS and an MS on another CS are the same object, just because one of the Participants is common to both CSs. In the transfer-between-agents example, although one of the Participants is common to the two CSs, this is not true for the other Participants.

Let's try to quantify the efficiency improvement. In the blind transfer case, the partial updates would at least have to include:
- the removal of P1 from CS1 (where P1 is the first agent and CS1 is the first CS);
- the removal of P2 from CS1 (where P2 is the transferred participant);
- the termination of CS1;
- the removal of CS1 from CSG1;
- the creation of CS2 (the CS that results from transfer);
- the addition to of CS2 to CSG1;
- the addition of P2 to CSG1;
- the addition of P3 to CS2 (where P3 is the second agent);
- the removal of P1 as a sender of MS1 (MS1 is from P1 to P2);
- the removal of P2 as a recipient of MS1;
- the termination of MS1;
- the creation of MS3;
- the addition of P3 as a sender of MS3;
- the addition of P2 as a recipient of MS3.

So all we are arguing about is whether we also include in the partial updates
EITHER (this I think is your proposal):
- the removal of P1 as a recipient of MS2;
- the addition of P3 as a recipient of MS2;

OR
- the removal of P1 as recipient of MS2;
- the removal of P2 as a sender of MS2;
- the termination MS2;
- the creation of MS4;
- the addition of P3 as a recipient of MS4;
- the addition of P2 as a sender of MS4.

So with the first option the total number of deltas is 14+2=16.
For the second option the total number of deltas is 14+6=20.

Some of the details might be wrong, but I hope you can see the point I am getting at. Looked at this way, the efficiency saving by recycling MS2 for use in consecutive CSs is relatively small. Or perhaps your intention is also to recycle MS1 (this time, the recipient remaining the same but the sender changing). That would reduce the number of deltas slightly further. The impact on XML size might not be quite in proportion to the reduction in the number of deltas, since by recycling MS2 it has to have a global identifier, not an identifier local to a CS. Or perhaps it could have an identifier local to a CSG.

I also see that with your proposal it doesn't force the MS to be recycled - an SRC could still choose to model it as separate MSs. However, in that case it would still need to use global identifiers for MSs.

I am not necessarily opposed to your proposal for recycling MS objects outside the context of a single CS - I can see advantages and disadvantages. I just want to make sure the group makes an informed decision.

John (as individual)

> > > > > > specific participant in several CS within the same 
> CSG as one
> > > > > recorded

---

From: Leon Portman <[email-masked]>
Date: Tue, 31 May 2011 16:19:05 +0300

Hello

I also having a problem even without a quantification of number of update messages that CS MS is remains same between different CS.  So I do prefer to keep it simple and keep it per CS.

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Friday, May 27, 2011 12:26 PM
To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R (rmohanr); [email-masked]
Subject: Re: [siprec] Can an MS object span several CSs in a CSG?

> This may not be the only callflow where MS partial-update is required 
> in this fashion. During -00 format draft, I thought that the 
> partial-update is not required but lot of folks raised the concern 
> that partial update is important. Current, -01 format draft is 
> designed to support partial-update. Now, You propose to restrict MS 
> partial-update across CS. IMO, it is a not good idea to restrict in 
> the protocol level. Anyway, I think that we need others opinion before 
> conclude here.

So all we are arguing about is whether we also include in the partial updates EITHER (this I think is your proposal):
- the removal of P1 as a recipient of MS2;
- the addition of P3 as a recipient of MS2;

OR

John (as individual)

> 
> Enhancing label attribute across the multiple SIP message to tie 
> between Metadata XML and RS SDP m-line is possible. SRC has to ensure 
> that label for the given RS SDP m-line should have same label 
> throughout single CSG even though it span across multiple CS and 
> multiple RS. Even then, it will not meet partial-update requirement as 
> mentioned below in this mail thread. At this moment, I'm favoring URN 
> UUID and not label attribute
> enhancement.   
> 
> Please read inline
> 
> Thanks
> Partha
> 
> efficiency improvement during metadata updates. I doubt that this 
> alone is sufficient justification for having the MS persist from one 
> CS to another CS.
> 
> > 
> > scope is within single SIP message and not required to be unique in 
> > all SIP messages of a given dialog. </Partha>
> > > I think that is many cases, they will be treated as separate MSs 
> > > due to the complexities you mention. However, I am trying to
> understand if
> > > required. If not, then what is a use case? A concrete example 
> > > would help me, and potentially others, to better understand the
> > motivation behind