Subject: [siprec] Reason element usage

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 5 Mar 2013 23:15:44 +0530

Hi all,

As per draft-ietf-siprec-metadata-11, Reason element is a string and not
required to be as per RFC3326(SIP reason header). Could you please let us
know your opinion whether SIPREC has to follow "reason" element as string or
"reason" element has to be updated as per RFC 3326. 

Thanks
Partha

PS: See Sec 6.3.1 comment in the below mail for more details

-----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: Mary Barnes <[email-masked]>
Date: Tue, 5 Mar 2013 13:52:01 -0600

I think it would be better to follow the format of the Reason header
field as defined in RFC 3326.

Mary.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 6 Mar 2013 15:43:19 +0000

+1

Andy (As an individual).

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Mary Barnes
> Sent: 05 March 2013 19:52
> To: Parthasarathi R
> Cc: [email-masked]
> Subject: Re: [siprec] Reason element usage
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 6 Mar 2013 17:59:58 +0000

+1

I also prefer to have the format of the Reason header field as defined in
RFC 3326 rather than just having as "string".

Regards,
Ram

> On 06/03/13 9:13 PM, "Hutton, Andrew"
><[email-masked]> wrote:

>> Behalf Of

---

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

Hi all,

Please let us know in case anybody has objection for mandating reason
element format as defined in SIP reason header (RFC 3326) only. 

Thanks
Partha

> From: Ram Mohan R (rmohanr) [mailto:[email-masked]]
> Sent: Wednesday, March 06, 2013 11:30 PM
> To: Hutton, Andrew; Mary Barnes; Parthasarathi R
> Cc: [email-masked]
> >> > As per draft-ietf-siprec-metadata-11, Reason element is a string
> and
> >> not
> >> >>> <Partha> Agreed. SRS has to be remove. The updated text will
> look
> >> like
> >> >> <AndyH> Ok but still it really does not have anything to do with
> the
> >> case
> >> > 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.
> >> >
> >> >>>> 4. Section 6.2.2 States "Each Communication Session Group
> object
> >> has
> >> >>> to
> >> >>>> potentially different SRCs".  Is it really the case that there
> can
> >> be
> >> >>> <Partha> Multiple SRC to SRS is supported in metadata model
> wherein
> >> how
> >> >>> of SIPREC. It is stated in both Sec 6.2.1 and Sec 6.2.2.
> Multiple
> >> RS
> >> > 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
> >> > I agree with Andy that just having a string, that might or might
> not
> >> be
> >> >>>> 7. Section 6.3.1. The last paragraph which starts "This
> document
> >> does
> >> >>>> a CS after it has been delivered..." does not appear to be
> useful
> >> to
> >> >>> me
> >> >>>> and could be removed.
> >> >>>>
> >> >>> The discussion happened very long back and in case it is
> required,
> >> I
> >> >>> will
> >> >> <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
> >> > info about desired retention policy, and we wanted to make it
> clear
> >> that

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Mar 2013 03:57:17 +0800

I have some questions about this idea. What is the goal? How closely do 
you want to follow the Reason header (RFC3326)?

- 3326 doesn't use xml, so at best it provides a conceptual model.
- each reason-value consists of a protocol name, cause number
   for that protocol, and some text. The currently defined protocols
   are SIP and Q.850. But I don't think either the SIP or Q.850
   causes will make any sense for siprec.
- 3326 allows multiple reason-values.
   I doubt that makes any sense for siprec.

So I *think* what people mean when they say to copy the reason header is 
that we should provide both a machine-understandable numeric value plus 
a human-friendly text value. But then we will need to define our own 
numeric values. Unfortunately, doing that means that we need to open up 
discussion about what numeric values we should define. Maybe that will 
be a useful discussion, maybe not. But it will take some time.

Is it worth it?
Or can we live with a string? I don't think we expect any programatic 
recovery action, so a machine readable value isn't so important.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Mar 2013 11:12:27 +0800

After some side discussions I realize I was wrong, and we do want to be 
compatible with the Reason header, so that we can copy values for the 
CS. So then the question is: HOW?

We could just copy the full value of the Reason header, as unparsed 
text, with parameters and everything. But that seems gross to me.

I see a couple of plausible syntaxes. Here are some examples:

<reason cause="200" protocol="SIP">Call completed elsewhere</reason>
<reason cause="16" protocol="Q.850">Terminated</reason>

OR

<reason>
  <protocol>  SIP </protocol>
  <cause> 200 </cause>
  <text> Call completed elsewhere </text>
</reason>
<reason>
  <protocol>  Q.850 </protocol>
  <cause> 16 </cause>
  <text> Terminated </text>
</reason>

Note that in either case we need the schema to permit multiple instances 
of <reason>, because you can have multiple reasons in a Reason header.

I personally prefer the former for style and conciseness, but I can live 
with the other one too.

	Thanks,
	Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 11 Mar 2013 04:12:10 +0000

> On 11/03/13 8:42 AM, "Paul Kyzivat" <[email-masked]> wrote:

><reason cause="16" protocol="Q.850">Terminated</reason>

I also prefer the above approach as its compact when compared to other
representation below.

Ram

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 12 Mar 2013 14:04:13 +0000

+1

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ram Mohan R (rmohanr)
> Sent: Monday, March 11, 2013 12:12 AM
> To: [email-masked]

---

From: Mary Barnes <[email-masked]>
Date: Tue, 12 Mar 2013 09:06:06 -0500

I also prefer the first style.

Thanks,
Mary.

On Sun, Mar 10, 2013 at 10:12 PM, Paul Kyzivat <[email-masked]> wrote:
> compatible with the Reason header, so that we can copy values for the CS. So
> then the question is: HOW?
>
> We could just copy the full value of the Reason header, as unparsed text,
> with parameters and everything. But that seems gross to me.
>
> Note that in either case we need the schema to permit multiple instances of
> <reason>, because you can have multiple reasons in a Reason header.
>