Subject: [siprec] SIP Recording Metadata Open item : Communication Session Attributes -Summary so far

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 22 Oct 2010 18:58:42 +0530

HI all,

Here is the Summary of some of the attributes that we discussed on CS.
Please use this thread to close on the open issues listed below

Attributes:

1) Direction, Scope, Initiator, internal/external:

The problem with all these three attributes is SIP might provide a clue,
but in some cases that might be misleading.

e.g calls established using 3PCC  Or conference

Do we need to provision these attributes in the metadata  model and have
values like "Unknown" in case where it's not possible to determine? OR
should we leave these as application specific attributes and store as
part of App Data in the model ?

2) Call ID:

We all seem to agree the need of a Unique ID but is cannot be call ID
for various reasons [e.g B2BUA in the path]. Other suggestions are
SessionID proposed in SIPSCOTCH on which We have not seen much progress.
IMO we can have a provision in Metadata model for a unique ID the value
of which can be determined when we come up with solution for SIPREC.
Thoughts ?

3) Call Termination Reason:

Who terminated the call" is another example of application information
that is not necessarily available (reliably) from SIP. The Reason header
in BYE may provide the required information.

 Direction of BYE may indicate "who terminated the call" in two party
call. Again, this is fuzzy in terms of conference or multi-party call or
cases where 3PCC/B2BUA issues a BYE. 

Should we have this attribute as part of model or leave it to be part of
App Data ?

Other attributes for which we seem to have consensus:

Information that the SRC has regarding privacy of information to be
recorded can be recorded in Model. Can this  be put as attributes in CS
?

Regards,

Ram

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 22 Oct 2010 16:07:10 +0200

In general, I don't have an opinion as to whether these attributes need to be identified explicitly in the metadata model or just left as generic application-specific data. However, I would make the point that any extensions to SIP or any other mechanism by which the SRC can obtain this information from diverse sources (e.g., a 3PCC application) should be outside the scope of SIPREC.

Also I am not sure whether, where application level information is not available to the SRC, the SRC should regard it as unknown or make a best guess based on information from SIP.

John (as individual)

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
> Sent: 22 October 2010 14:29
> To: [email-masked]
> Subject: [siprec] SIP Recording Metadata Open item : 
> Communication Session Attributes -Summary so far
> 
> HI all,
> 
>  
> 
> Here is the Summary of some of the attributes that we 
> discussed on CS. Please use this thread to close on the open 
> issues listed below
> 
>  
> 
> Attributes:
> 
>  
> 
> The problem with all these three attributes is SIP might 
> provide a clue, but in some cases that might be misleading.
> 
> Do we need to provision these attributes in the metadata  
> model and have values like "Unknown" in case where it's not 
> possible to determine? OR should we leave these as 
> application specific attributes and store as part of App Data 
> in the model ?
> 
>  
> 
> 2) Call ID:
> 
> We all seem to agree the need of a Unique ID but is cannot be 
> call ID for various reasons [e.g B2BUA in the path]. Other 
> suggestions are SessionID proposed in SIPSCOTCH on which We 
> have not seen much progress. IMO we can have a provision in 
> Metadata model for a unique ID the value of which can be 
> determined when we come up with solution for SIPREC. Thoughts ?
> 
>  
> 
> Who terminated the call" is another example of application 
> information that is not necessarily available (reliably) from 
> SIP. The Reason header in BYE may provide the required information.
> 
>  Direction of BYE may indicate "who terminated the call" in 
> two party call. Again, this is fuzzy in terms of conference 
> or multi-party call or cases where 3PCC/B2BUA issues a BYE. 
> 
>  
> 
> Should we have this attribute as part of model or leave it to 
> be part of App Data ?
> 
>  
> 
> Information that the SRC has regarding privacy of information 
> to be recorded can be recorded in Model. Can this  be put as 
> attributes in CS ?
> 
>  
> 
> Regards,
> 
> Ram
> 
>  
> 
>  
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Oct 2010 10:59:13 -0400

On 10/22/2010 10:07 AM, Elwell, John wrote:
> In general, I don't have an opinion as to whether these attributes need to be identified explicitly in the metadata model or just left as generic application-specific data.

I don't have a *strong* opinion on it *yet*.
But my inclination is that if these are *important* concepts then they 
ought to be explicitly in the metamodel. Otherwise they will become 
impediments to interop later on.

> However, I would make the point that any extensions to SIP or any other mechanism by which the SRC can obtain this information from diverse sources (e.g., a 3PCC application) should be outside the scope of SIPREC.

I agree with this.

> Also I am not sure whether, where application level information is not available to the SRC, the SRC should regard it as unknown or make a best guess based on information from SIP.

ISTM that the SRC will be "application specific" in some sense, so it 
can make decisions that are appropriate in its context.

	Thanks,
	Paul

> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Henry Lum" <[email-masked]>
Date: Tue, 26 Oct 2010 09:40:43 -0700

> impediments to interop later on.

[[hlum]] I agree. We should agree on a common set of concepts to be
included as attributes rather than application data, but not
require/define SRC on how these attributes are collected. Should we also
include examples of how SRC sets the attributes or leave it out of the
scope of this document?

> 
> > However, I would make the point that any extensions to SIP or any
> other mechanism by which the SRC can obtain this information from
> diverse sources (e.g., a 3PCC application) should be outside the scope
> of SIPREC.
> 
> I agree with this.
> 
> > Also I am not sure whether, where application level information is
> not available to the SRC, the SRC should regard it as unknown or make
a
> best guess based on information from SIP.
> 

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Oct 2010 13:20:46 -0400

On 10/26/2010 12:40 PM, Henry Lum wrote:
> require/define SRC on how these attributes are collected.

I don't think we should require how (or in most cases, if) the SRC gets 
these attributes. But I think we should have some plausible explanation 
for how an SRC might get them. Otherwise we are just creating a fantasy.

> Should we also

How they are set is part of a mechanism, which will be a different draft 
(or competing drafts).

But I was talking to Ram and Partha this morning, and we concluded that 
in addition to the UML class model we are developing now, we should work 
out a few use cases as instance diagrams. I think that will help people 
to understand. I don't know if there will be time to do that before the 
meeting. If not, we'll get it done after the meeting.

	Thanks,
	Paul