Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-19.txt

From: Paul Kyzivat <[email-masked]>
Date: Mon, 1 Feb 2016 13:22:17 -0500

On 1/30/16 4:43 AM, Ram Mohan R (rmohanr) wrote:
> Addressed the review comments from AD review.

I reviewed all the changes. I noted one issue:

* Section 6.5.1:

This starts out saying "Participant has a single defined attribute", but 
is then immediately followed by the description of two attributes!

	Thanks,
	Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 2 Feb 2016 01:44:20 +0000

Paul,

That is a typo. There are two attributes. I will fix the first line. Will
wait for any more feedback from WG/Alissa and fix this along with them.

Regards,
Ram

-----Original Message-----
From: siprec <[email-masked]> on behalf of Paul Kyzivat
<[email-masked]>
Date: Monday, 1 February 2016 at 11:52 PM
To: "[email-masked]" <[email-masked]>
Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-19.txt

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

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 2 Feb 2016 14:43:04 -0800

Thanks for doing an update. This is looking better. I would suggest that one of the authors do a careful edit pass of the document to check for consistent use of terminology, capitalization and field names. For example, "associate-time,” “associateTime” and "association-time” are all used in different places. Pick one and use it everywhere, and do the same for all the field names that get repeated. Normally I would say the RFC Editor can catch this stuff but for a model like this I think precision is important to make sure it’s implementable and interoperable.

Section 6.3.1: 

"The reason XML element has 'protocol' as an attribute, which indicates the protocol from which the reason string is derived.” What other protocols are possibilities here besides SIP, if any?

s/to indicate the group to which the enclosing session belongs./to indicate the group_id to which the enclosing session belongs./

Section 6.5.1:

s/SRCs local policy MAY also be used/SRC’s local policy MAY be used/

"Name represents participant name(SIP display name) or dialed number (DN) (when known).” If there is a reason to prefer one over the other, that should be stated. And I think there is also some clarification required about whether the expectation is that multiple tuples included for the same participant will have the same name.

Section 6.6:

Still think it would help to include an example of a capability that would be desirable to record.

Alissa

> On Jan 30, 2016, at 1:43 AM, Ram Mohan R (rmohanr) <[email-masked]> wrote:
> 
> From: siprec <[email-masked]> on behalf of
> "[email-masked]" <[email-masked]>
> Date: Saturday, 30 January 2016 at 3:11 PM
> To: "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-19.txt
> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the SIP Recording Working Group of the IETF.
>> 
>>       Title           : Session Initiation Protocol (SIP) Recording
>> Metadata
>>       Authors         : Ram Mohan Ravindranath
>>                         Parthasarathi Ravindran
>>                         Paul Kyzivat
>> 	Filename        : draft-ietf-siprec-metadata-19.txt
>> 	Pages           : 31
>> 	Date            : 2016-01-30
>> 
>> Abstract:
>>  Session recording is a critical requirement in many communications
>>  environments such as call centers and financial trading.  In some of
>>  these environments, all calls must be recorded for regulatory,
>>  compliance, and consumer protection reasons.  Recording of a session
>>  is typically performed by sending a copy of a media stream to a
>>  recording device.  This document describes the metadata model as
>>  viewed by Session Recording Server(SRS) and the Recording metadata
>>  format.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/
>> 
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-siprec-metadata-19
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-siprec-metadata-19
>> 
>> 
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 3 Feb 2016 05:47:44 +0000

Hi Alissa, 

Thanks for the feedback. I will fix the associate-time inconsistency. Also
will do a check on other similar errors.
See inline for responses.

-----Original Message-----
From: Alissa Cooper <[email-masked]>
Date: Wednesday, 3 February 2016 at 4:13 AM
To: Cisco Employee <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-19.txt

>Thanks for doing an update. This is looking better. I would suggest that
>one of the authors do a careful edit pass of the document to check for
>consistent use of terminology, capitalization and field names. For
>example, "associate-time,² ³associateTime² and "association-time² are all
>used in different places. Pick one and use it everywhere, and do the same
>for all the field names that get repeated. Normally I would say the RFC
>Editor can catch this stuff but for a model like this I think precision
>is important to make sure it¹s implementable and interoperable.
>
>Section 6.3.1: 
>
>"The reason XML element has 'protocol' as an attribute, which indicates
>the protocol from which the reason string is derived.² What other
>protocols are possibilities here besides SIP, if any?

In most cases this is going to be SIP which is the reason why the default
value of this XML element is ³SIP².  However there are still Gateways that
may be part of CS which would use Q.850 cause codes in the reason header
of BYE or other SIP disconnect messages.  The <reason> XML element here is
derived from SIP reason header defined in RFC3326 which allows both SIP
and Q.850 and hence we also allow both of them.

>
>s/to indicate the group to which the enclosing session belongs./to
>indicate the group_id to which the enclosing session belongs./
>
>Section 6.5.1:
>
>s/SRCs local policy MAY also be used/SRC¹s local policy MAY be used/
>
>"Name represents participant name(SIP display name) or dialed number (DN)
>(when known).² If there is a reason to prefer one over the other, that
>should be stated.

I don¹t think there is a preference here. IMO this is policy at SRC which
decides what to pick up.

> And I think there is also some clarification required about whether the
>expectation is that multiple tuples included for the same participant
>will have the same name.

IMO names are most likely to be same even when multiple tuples are
present. The SRC will just pick up the display from the URI and use it as
is. If for whatever reasons the display name is different in the two AoRs
(say SIP and TEL URI has different display names one may contain first
name and other last name e.t.c), then SRC may end up in sending different
names.

 I don¹t think we should mandate SRC to use same name.

>would be desirable to record.

Sure.  I can add some text on one or two example capabilities of
participant that may be useful to record. How the recorder uses this
capability indicated in the metadata is outside the scope.

A simple example is- In a CS one of the participant may be a ³automata²
and would likely do a auto-answer when a call is received, play some
prompts and then transfer to a agent. Sending this information (about the
capability of participant that it is a automata) would be useful to
recorder on how it wants to handle that part of recorded media.
Another example - In a conference CS, you can have participants who are
playing the role of ³Focus² these participants does not contribute to any
media in the CS, however they switch the media received from one
participant to every other participant in the CS. Having the information
about the participant (that it is a Focus) indicated in the metadata to
recorder would be useful for recorder to manage the participant to media
stream mapping while doing playback.

Ram

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 4 Feb 2016 12:38:16 +0000

WG/Alissa,

Please find the diffs with below comments addressed and also other errors
I noted.
Let me know your feedback.

Regards,
Ram