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

["Charles Eckel (eckelcu)" <[e-mail]>]

Please excuse the delay. I am catching up after having been away on
vacation.
In light of this better understanding of the use case, I also prefer the
option favored by John and Leon to model as a separate MS. In this
specific case, I would expect the properties of the MS to change when A
is transferred to C, so I expect the overhead in creating a new MS vs.
reusing the same MS to be minimal and not worth the added complexity to
the model.

Cheers,
Charles

> -----Original Message-----
> From: Leon Portman [mailto:[e-mail]]
> Sent: Tuesday, May 31, 2011 6:19 AM
> To: Elwell, John; Parthasarathi R (partr); Charles Eckel (eckelcu);
Ram Mohan R (rmohanr);
> [e-mail]
> Subject: RE: [siprec] Can an MS object span several CSs in a CSG?
> 
> 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: [e-mail] [mailto:[e-mail]] On
Behalf Of Elwell, John
> Sent: Friday, May 27, 2011 12:26 PM
> To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R
(rmohanr); [e-mail]
> Subject: Re: [siprec] Can an MS object span several CSs in a CSG?
> 
> 
> 
> 
> > -----Original Message-----
> > From: Parthasarathi R (partr) [mailto:[e-mail]]
> > Sent: 26 May 2011 15:55
> > To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R (rmohanr);
> > [e-mail]
> > Subject: RE: [siprec] Can an MS object span several CSs in a CSG?
> >
> > 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.
> [JRE] Agreed the Participant remains the same, but we are discussing
MS.
> 
> > 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.
> [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)
> 
> 
> >
> > 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:[e-mail]]
> > Sent: Wednesday, May 25, 2011 7:17 PM
> > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R
> > (rmohanr); [e-mail]
> > Subject: RE: [siprec] Can an MS object span several CSs in a CSG?
> >
> >
> >
> > > -----Original Message-----
> > > From: Parthasarathi R (partr) [mailto:[e-mail]]
> > > Sent: 25 May 2011 08:48
> > > To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R (rmohanr);
> > > [e-mail]
> > > Subject: RE: [siprec] Can an MS object span several CSs in a CSG?
> > >
> > > John,
> > >
> > >
===================================================================
> > > > 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
> > > [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>
> > [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.
> >
> > >
> > > ==============================================================
> > > ==========
> > > =======================
> > > 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.
> > [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>
> >
> > > 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>
> > [JRE] But I think we could nail that down as a requirement of the
> > SIPREC protocol.
> >
> > John (as individual)
> >
> > >
> > > Thanks
> > > Partha
> > >
> > > John (as individual)
> > >
> > > >
> > > > 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';
> > > > '[e-mail]'
> > > > Subject: RE: [siprec] Can an MS object span several CSs in a
CSG?
> > > >
> > > > 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
> > > >
> > > > > -----Original Message-----
> > > > > From: Ram Mohan R (rmohanr)
> > > > > Sent: Tuesday, May 24, 2011 9:36 AM
> > > > > To: Charles Eckel (eckelcu); Parthasarathi R (partr);
> > > Elwell, John;
> > > > > [e-mail]
> > > > > 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
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [e-mail]
> > > [mailto:[e-mail]] On
> > > > > > Behalf Of Charles Eckel (eckelcu)
> > > > > > Sent: Tuesday, May 24, 2011 9:11 PM
> > > > > > To: Parthasarathi R (partr); Elwell, John; [e-mail]
> > > > > > Subject: Re: [siprec] Can an MS object span several CSs
> > > in a CSG?
> > > > > >
> > > > > > 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
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: [e-mail]
> > > > [mailto:[e-mail]] On
> > > > > > Behalf Of Parthasarathi R (partr)
> > > > > > > Sent: Tuesday, May 24, 2011 4:26 AM
> > > > > > > To: Elwell, John; [e-mail]
> > > > > > > Subject: Re: [siprec] Can an MS object span several CSs
> > > > in a CSG?
> > > > > > >
> > > > > > > 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: [e-mail]
> > > > [mailto:[e-mail]] On
> > > > > > Behalf
> > > > > > > Of Elwell, John
> > > > > > > Sent: Tuesday, May 24, 2011 1:06 PM
> > > > > > > To: [e-mail]
> > > > > > > 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
> > > > > > > [e-mail]
> > > > > > > https://www.ietf.org/mailman/listinfo/siprec
> > > > > > > _______________________________________________
> > > > > > > siprec mailing list
> > > > > > > [e-mail]
> > > > > > > https://www.ietf.org/mailman/listinfo/siprec
> > > > > > _______________________________________________
> > > > > > siprec mailing list
> > > > > > [e-mail]
> > > > > > https://www.ietf.org/mailman/listinfo/siprec
> > > >
> > >
> >
> _______________________________________________
> siprec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/siprec