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

["Elwell, John" <[e-mail]>]

OK, I understand. So I will go along with the majority. Any other opinions whether we need global ID or local ID for MS?

John


> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]]
> Sent: 15 June 2011 15:43
> To: Elwell, John
> Cc: [e-mail]
> Subject: Re: [siprec] Can an MS object span several CSs in a CSG?
>
>
>
> On 6/15/2011 9:55 AM, Elwell, John wrote:
> > Paul,
> >
> > But if the two SRCs are somehow cooperating to the extent
> that they can share the same global ID for the CS, could they
> not also share the same local ID for the MS? Why does it need
> to be a global ID?
>
> They could *know* each other's local id for the MS.
> They might even agree to use the *same* value for the local id.
>
> E.g. we have SRC#1 and SRC#2, each using 123 as the local id for the
> "same" stream.
>
> But to the SRS, there is one MS with id SRC#1:123, and
> another MS with
> SRC#2:123. It does not know they are the same. (That is the point of
> local scoping.)
>
> So even though the two SRCs know they are talking about the
> same MS they
> have no way to tell that to the SRS.
>
>       Thanks,
>       Paul
>
> > John
> >
> >
> >> -----Original Message-----
> >> From: [e-mail]
> >> [mailto:[e-mail]] On Behalf Of Paul Kyzivat
> >> Sent: 14 June 2011 16:31
> >> To: [e-mail]
> >> Subject: Re: [siprec] Can an MS object span several CSs in a CSG?
> >>
> >> John,
> >>
> >> Consider another case: two SRCs in the same CS (perhaps one at each
> >> "end".) They are both sending metadata about the same CS and MSs.
> >>
> >> Suppose they want to cooperate with each other. They have the
> >> potential
> >> to use the same ID to reference the CS, so that the SRS will
> >> know they
> >> are talking about the same one. But with RS-specific MS ids
> >> there is no
> >> way for them to indicate that they are talking about the same
> >> MSs. With
> >> global MS ids, they could accomplish this.
> >>
> >>        Thanks,
> >>        Paul
> >>
> >> On 6/14/2011 11:03 AM, Elwell, John wrote:
> >>> Partha,
> >>>
> >>> Thanks for the examples. The character count for the delta
> >> is about 2500 when a new MS is created compared to about 2100
> >> when the MS is retained. This seems to be in line with my
> >> previous gut feeling.
> >>>
> >>> Concerning the need for "SRS implementers to guess how old
> >> MS and new MS are related", I don't think they are related,
> >> except by having other things in common like a common
> >> participant or a common CSG.
> >>>
> >>> John (as individual)
> >>>
> >>>> -----Original Message-----
> >>>> From: Parthasarathi R (partr) [mailto:[e-mail]]
> >>>> Sent: 14 June 2011 13:15
> >>>> To: Charles Eckel (eckelcu); Leon Portman; Elwell, John; Ram
> >>>> Mohan R (rmohanr); [e-mail]
> >>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG?
> >>>>
> >>>> Hi all,
> >>>>
> >>>> Sorry for the delay. Just to double confirm everybody
> >>>> understanding with
> >>>> SIP message example, I added the example with creating new MS and
> >>>> reusing the same MS as an attachment with this mail.
> >>>>
> >>>> Please note that creating new MS is putting SRS
> >> implementers to guess
> >>>> how old MS and new MS are related. Also, few scenario like
> >>   Even after
> >>>> looking into the example, the intention is to use local
> >> variable, I'm
> >>>> ok.
> >>>>
> >>>> Thanks
> >>>> Partha
> >>>>
> >>>> -----Original Message-----
> >>>> From: Charles Eckel (eckelcu)
> >>>> Sent: Friday, June 10, 2011 10:57 PM
> >>>> To: Leon Portman; Elwell, John; Parthasarathi R (partr);
> >> Ram Mohan R
> >>>> (rmohanr); [e-mail]
> >>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG?
> >>>>
> >>>> 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
> >>>>
> >>> _______________________________________________
> >>> siprec mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/siprec
> >>>
> >> _______________________________________________
> >> siprec mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/siprec
> >>
> >
>