Subject: Re: [siprec] SIPREC Charter Update Proposal.

From: Paul Kyzivat <[email-masked]>
Date: Thu, 02 Jan 2014 10:53:03 -0500

Happy New Year Andy!

On 12/31/13 6:43 AM, Hutton, Andrew wrote:
> Would like some more comments on the proposed charter update so I changed subject so it is more obvious what this is about.

I've been slacking off for the holidays. So thanks for the resend.

> Andy
>
>
>
> -----Original Message-----
> From: siprec [mailto:[email-masked]] On Behalf Of Hutton, Andrew
> Sent: 23 December 2013 15:24
> To: Paul Kyzivat; [email-masked]
> Subject: Re: [siprec] Reminder: Additional use cases for draft-kyzivat-siprec-conference-use-cases-00
>
> Hi All,
>
> Since nobody posted any new uses cases I went back to our discussion in Vancouver and tried to see what we appeared to have consensus on in the meeting.
>
>>From that I have formed a proposal for a charter update which is given below and also attached (with changes highlighted).

I don't see any highlights. I did a "visual" diff, and found mostly a 
big deletion (for stuff already done) and a small addition to restrict 
to SIP, plus the milestone changes. Did I miss anything?

> It seems everybody agreed that we need to clarify that SIPREC is limited to SIP based systems and that MSRP recording needs to be added.
>
> It also seemed to me that there was no consensus on adding the generic case of document/application sharing but if this was limited to being a video session in which the content type (RFC 4796) formed part of the metadata then probably we would have consensus.  So I included a suggested reference to this as a milestone please comment on whether this makes sense.

It was always our intent that document/application sharing be recorded 
using "normal" media. (Audio/video). I think what you have proposed for 
the last milestone is in line with that.

I do think there is likely to be need for some discussion about *how* 
these can be used for this. (E.g., describing that a conference server 
might do document sharing in the CS via the web, but encode it as audio 
and video for the RS.) It remains to be seen whether that will turn into 
any normative requirements.

Do you see that fitting within the milestones as you have written them?

> There was a lot of discussion in the Vancouver meeting about defining a generic mechanism to record media without the need to come back to SIPREC every time new media types or metadata needs to be recorded.  There has been no use cases submitted or discussion on possible mechanism since the meeting so I see no way to progress this at present.
>
>
> Please can provide comments and Paul and others who stated they would contribute can you confirm that you still intend to do so and that this charter proposal is acceptable to you.

Yes, we still plan to submit on this. Assuming agreement, we will 
contribute prior to the London meeting.

	Thanks,
	Paul

> Regards
> Andy
>
>
>
> =====================================
> SUGGESTED CHARTER - UPDATE
> =====================================
>
> Session recording is a critical requirement in many business communications environments such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control, business analytics, or consumer protection. Recording is typically done by sending a copy of the media to the recording devices. The working group will determine requirements and produce a specification for a protocol that will manage delivery of media, in SIP based systems (including audio, video, MSRP instant message sessions) from an end-point that originates media, or that has access to it, to a recording device. PBX and recording vendors today implement proprietary, incompatible mechanisms to facilitate recording. A standard protocol will reduce the complexity and cost of providing such recording services.
>
> The group will define these issues and rationalize with IETF standards and practices. This includes encryption, NAT traversal, operations and manageability, SIP-enabled firewalls, authorization, and security.
> The scope explicitly does not include recording any of the extended session attributes being defined by the CLUE WG. (These may be addressed by a subsequent effort.)
>
> The group will produce:
>
> * Updated Requirements, Use Cases, Architecture draft
>
> * Specification for Session Recording Protocol and Metadata
>
> Milestones
>
> DONE   	Use Cases and Requirements to IESG as Informational RFC
> MAR 2014 	Submit Architecture to IESG as Informational RFC
> JUN 2014 	Submit protocol draft to IESG as Proposed Standard RFC
> AUG 2014 	Submit Metadata model and format to IESG as Proposed Standard RFC
> AUG 2014 	Submit SIPREC Call Flows draft to IESG as an informational RFC
> ??? 2014 	Conference Recording Use Cases and Requirements to IESG as Informational RFC
> ??? 2014 	Conference Recording Architecture to IESG as Informational RFC
> ??? 2014 	Protocol and metadata for MSRP recording to IESG as Proposed Standard RFC
> ??? 2014 	Protocol and metadata for capturing the content (RFC 4796) of the media stream.
>
>
> ============================================================================================
>
>
>
>> -----Original Message-----
>> From: siprec [mailto:[email-masked]] On Behalf Of Paul Kyzivat
>> Sent: 21 November 2013 18:44
>> To: [email-masked]
>> Subject: Re: [siprec] Reminder: Additional use cases for draft-kyzivat-
>> siprec-conference-use-cases-00
>>
>> I still haven't seen anything on this subject.
>> I *thought* there were multiple people in the siprec session in
>> Vancouver that seemed to have other use cases related to media.
>>
>> If so, better speak up, or IIUC we are going to treat the use cases we
>> have as bounding the new scope.
>>
>> 	Thanks,
>> 	Paul
>>
>> On 11/15/13 9:31 AM, Paul Kyzivat wrote:
>>> One of the action items from the meeting last week was:
>>>
>>>> chairs: use cases to the list in the next couple of weeks.  After
>> that,
>>>> we will decide if we need charter language.  If your use case is not
>>>> contributed, it will not be considered in the milestones.
>>>
>>> The above is a little vague about the timing. Two weeks from the end
>> of
>>> the meeting would be Friday, November 23. (Hopefully the chairs will
>>> clarify this.)
>>>
>>> This is important because there was some desire to tighten up the
>> scope
>>> of the rechartering to encompass only the mentioned use cases.
>>>
>>> I'll be happy to incorporate additional popular use cases even before
>>> this draft becomes a wg draft. (But please send text.)
>>>
>>> While the name of the draft is about conferences, the use cases
>> include
>>> additional media support. (Maybe we should rename the draft.) And it
>>> seemed that much of the interest was about additional media.
>>>
>>>       Thanks,
>>>       Paul
>>>
>>>
>>> _______________________________________________
>>> siprec mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/siprec
>>>
>>
>> _______________________________________________
>> siprec mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/siprec
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>