Subject: [siprec] Common unique-id from multiple SRC to SRS [was RE: Comments on draft-ietf-siprec-metadata-10.]

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 7 Mar 2013 22:38:00 +0530

Andy,

Sorry for the delay reply. As Paul mentioned, common unique-id from multiple
SRC to SRS shall be discussed in Sec 6.10. The point to be noted is that SRS
should be in the position to receive the common unique-id from multiple SRC
and how unique-id is exchanged between SRCs is outside the scope of SIPREC.
Please let us know in case you have any concern in this approach.

Thanks
Partha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: Saturday, February 02, 2013 11:25 PM
> To: [email-masked]
> Subject: Re: [siprec] Comments on draft-ietf-siprec-metadata-10.
> 
> Some comments inline.
> 
> On 1/29/13 11:32 AM, Hutton, Andrew wrote:
> 
> >>> 3. Section 6.2.1 Which discusses CS session attributes includes the
> >>> following statement: "SRC (or SRS) is responsible for ensuring the
> >>> uniqueness of Unique-ID in case multiple SRC interacts with the
> same
> >>> SRS.".  I don't see how the SRS can be responsible for this and
> think
> >>> the statement is unnecessary and could simple be replaced with a
> >>> reference to 6.10 which stated describes how unique-id's are
> created.
> >>>
> >> <Partha> Agreed. SRS has to be remove. The updated text will look
> like
> >> "SRC is responsible for ensuring the uniqueness of Unique-ID in case
> >> multiple SRC interacts with the same SRS." </Partha>
> >>
> >
> > <AndyH> Ok but still it really does not have anything to do with the
> case of multiple SRC's as the SRC is of course unaware that there is
> another SRC so I still think we could just refer to section 6.10.
> </AndyH>.
> 
> IMO the point to get across is that multiple SRCs are *permitted* to
> refer to the same entities by using a common UUID. (The SRS must not
> consider this an error.) *How* the SRCs determine they are referring to
> the same entity and obtain the same UUID for it is out of scope for
> this
> document.
> 
> Perhaps it would be better to discuss this in 6.10.
> 
> >>> 4. Section 6.2.2 States "Each Communication Session Group object
> has
> >> to
> >>> be associated with one or more RS [Here each RS can be setup by the
> >>> potentially different SRCs".  Is it really the case that there can
> be
> >>> more than one RS per CS Group? If it is because each RS can be
> >>> established by different SRC's then I assume this should impact the
> >>> object model which only describes the metadata generated by a
> single
> >>> SRC.
> >>>
> >> <Partha> Multiple SRC to SRS is supported in metadata model wherein
> how
> >> SRC Communicate with each other for CSG/CS unique id is outside the
> >> scope
> >> of SIPREC. It is stated in both Sec 6.2.1 and Sec 6.2.2. Multiple RS
> >> shall  be associated with single CSG. </Partha>
> >
> > <AndyH>I am not convinced that we can say anything about the multiple
> SRC case other than making sure we keep the id's unique I don't think
> we said anything about this in the architecture draft. Can you describe
> the use case and requirement that this covers.
> 
> Same comment as above.
> 
> >>> 6. Section 6.3.1 Communication Session Attributes. I think we need
> >> more
> >>> detail as to the format of the Termination Reason. It would
> probably
> >> be
> >>> useful to say that it is formatted according to the rules of
> RFC3326
> >> if
> >>> that is the intention and give an example in section 7.1.
> >>>
> >> <Partha> Reason XML element is a string which may be as per RFC 3326
> >> and
> >> there is no Mandate to strictly follow RFC 3326Please let me whether
> it
> >> is sufficient to provide the reason XML element usage in the example
> >> draft.
> >> </Partha>
> >
> > <AndyH> Lets have a thread on that as well what is the purpose of the
> reason attribute if it is just free form text it is I think more useful
> if we follow a defined structure such as RFC3326 for this. </AndyH>
> 
> I agree this is worthy of some discussion as to whether 3326 is
> sufficient, or if we need a wider range of causes than that provides.
> 
> I agree with Andy that just having a string, that might or might not be
> a standard string from 3326 is dubious. With that you can never be
> certain if the reason has the exact semantics of a 3326 reason.
> 
> So I'm inclined to think we should be able to carry everything from a
> Reason header.
> 
> >>> 7. Section 6.3.1. The last paragraph which starts "This document
> does
> >>> not specify attributes relating to what should happen to a
> recording
> >> of
> >>> a CS after it has been delivered..." does not appear to be useful
> to
> >> me
> >>> and could be removed.
> >>>
> >> <Partha> This statement was added after long discussion in mailing
> >> alias
> >> and earlier IETF meeting about "when CS actually terminates".
> >> The discussion happened very long back and in case it is required, I
> >> will
> >> Search for the archive to find the exact timeframe at which this
> >> Statement was added </Partha>
> >
> > <AndyH> But this statement seems to be about how long the SRS might
> retain the recording which has nothing to do with metadata and I don't
> think it is useful to put possible usages of extension data in the
> draft when any such usage will be proprietary and not interoperable. I
> think this paragraph should be removed. </AndyH>
> 
> Certainly we can't enumerate all the things we *don't* cover.
> IIRC this was added because some people expected that we *would*
> include
> info about desired retention policy, and we wanted to make it clear
> that
> we were not. I see no harm in that.
> 
> 
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Sat, 9 Mar 2013 16:00:39 +0000

Getting back late on this. I see Andy's question here is

<AndyH>I am not convinced that we can say anything about the multiple SRC
case other than making sure we keep the id's unique I don't think we said
anything about this in the architecture draft. Can you describe the use
case and requirement that this covers.

I think there would definitely be use-cases  in real deployments where
there would be multiple SRCs for a single CS. A simplest use-case that I
have heard many times is recording solution for Financial trading centers
where they prefer to have redundant recordings (recorded to different
geographical sites). In such flows we *may* have multiple SRC's each
having its own RS and recording the same CS.

A simple scenario being both endpoints of a CS acting as SRC. You can
visualize this to the section 3.1.2 of architecture draft with both
endpoints having RS.

Ram

> On 07/03/13 10:38 PM, "Parthasarathi R" <[email-masked]>
>wrote:

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Sat, 9 Mar 2013 16:17:04 +0000

To add to the below another simple case a CS with two endpoints where each
point acts as SRC and records each side of the conversation via RS. So you
would have two RS from two SRCs for the same CS.

Ram

> On 09/03/13 9:30 PM, "Ram Mohan R (rmohanr)" <[email-masked]> wrote:

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 12 Mar 2013 17:52:38 +0000

Hi,

I understand the use case although it might be argued that these are not specified in RFC 6341 and therefore might be considered out of scope.

However the main issue is that if this is possible that the spec is clear when an SRS might expect to encounter the same identifier from different SRC's and what this means to an SRS that receives it. At present it does not appear to be.

Regards
Andy

> Behalf Of Ram Mohan R (rmohanr)
> Sent: 09 March 2013 11:17
> To: [email-masked]
> Subject: Re: [siprec] Common unique-id from multiple SRC to SRS [was
> RE: Comments on draft-ietf-siprec-metadata-10.]
> 
> SRC
> >>SRC to SRS shall be discussed in Sec 6.10. The point to be noted is
> that
> >>SRS
> >>should be in the position to receive the common unique-id from
> multiple
> >>SRC

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Mar 2013 03:20:17 +0800

> However the main issue is that if this is possible that the spec is clear when an SRS might expect to encounter the same identifier from different SRC's and what this means to an SRS that receives…

IMO this behavior in intrinsic to the way IDs and metadata are defined.
But I agree it might not be entirely clear, so we should do whatever we 
have to to ensure it *is* clear.

	Thanks,
	Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 13 Mar 2013 02:51:13 +0000

Can some one suggest on what text to include (in section 6.2.1)  to make
this clear ?
Do we need some text on what SRS needs to do if it receives same
identifier from two SRCs ?

I assume that we don't want to mention about how SRCs ensure the same
identifier is used for related RecordingSessions(of same CS).

Ram

> On 13/03/13 12:50 AM, "Paul Kyzivat" <[email-masked]> wrote:

>> I understand the use case although it might be argued that these are
>>not specified in RFC 6341 and therefore might be considered out of scope.
>>
>> However the main issue is that if this is possible that the spec is
>>clear when an SRS might expect to encounter the same identifier from
>>different SRC's and what this means to an SRS that receives it. At
>>present it does not appear to be.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Mar 2013 11:24:57 +0800

> identifier from two SRCs ?

I went looking for a place. 6.2.1 is not a sufficient place - that is 
only one place where there is a reference by id. The behavior applies to 
all references.

I finally decided there is no good place in the metadata document - it 
doesn't talk about SRC and SRS behavior. That is done in the protocol 
document.

I think the best place would be in section 9.2 of the protocol document.

How about adding the following at the end of that section:

"The metadata received by the SRS frequently contains ID elements used 
to cross reference one element to another. An element containing the 
definition of an ID, and an element containing a reference to that ID 
will often be received from the same SRC. But it is also valid for those 
elements to be received from different SRCs. The SRS MUST NOT consider 
this an error."

	Thanks,
	Paul