Subject: [siprec] SIPREC Milestone Update.

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 13 Mar 2014 18:49:19 +0000

During the IETF89 SIPREC meeting a discrepancy was identified between my slides showing the proposed new milestones and Paul's slides.

The chairs slides stated the following milestone:

"??? 2014 	Protocol and metadata for capturing the content (RFC 4796) of the media stream".

Whilst Paul's conference recording slides stated

"Dec 2014	Protocol and metadata for recording of document & application sharing to IESG as Proposed Standard RFC"

I posted this suggested change to the list as can be seen in the message below and received no comments. The rational for the suggestion is also given in the text below but is basically that we did not have consensus for recording of document and application sharing just for video with reference to the content.

Please give feedback as to whether the milestone with reference to RFC 4796 makes sense.

Regards
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).
> 
> 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.
> 
> 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.
> 
> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Mar 2014 10:36:24 -0400

Andy,

> Please give feedback as to whether the milestone with reference to RFC 4796 makes sense.

IMO limiting this to RFC 4796 is too narrow for the milestone. It may 
turn out that 4796 is *part* of the mechanism, but I certainly don't 
want to be limited to that. While it needs discussion, I have in mind to 
capture additional metadata, such as:
- the distinction between document, application, and screen sharing
- the name of the document or application

These won't always be available, but if they are they would be useful to 
record.

Also, while the intent is to capture presentations using video (and 
perhaps audio) media streams, we *may* also want to say something about 
*how* this is done.

And, if the presentation media includes audio as well as video, and the 
audio is distinct from the "room audio", we may want metadata to tie the 
audio and video together.

Note that I've phrased the above as *may* because IMO this stuff is all 
subject to debate. But I would like it to be within the scope of the 
milestone.

That is why I phrased the milestone the way I did.

The date for the milestone is another question. The December date is 
probably a little optimistic, but I'd rather do that than have it be 
pessimistic and just dawdle. But in the end the milestone dates are 
really up to the chairs and ADs.

	Thanks,
	Paul

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 20 Mar 2014 09:13:29 +0000

Paul,

The feedback we had during the IETF88 (Vancouver) meeting was that we could not extend SIPREC to generically cover "document & application" sharing as there is no standard to base this on. 

Can you suggest a milestone that is more precise that we can get consensus on?

Andy

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 14 March 2014 14:36
> To: Hutton, Andrew; [email-masked]
> Subject: Re: SIPREC Milestone Update.
> 
> Andy,
> 
> > During the IETF89 SIPREC meeting a discrepancy was identified between
> my slides showing the proposed new milestones and Paul's slides.
> >
> > "Dec 2014	Protocol and metadata for recording of document &
> application sharing to IESG as Proposed Standard RFC"
> >
> > I posted this suggested change to the list as can be seen in the
> message below and received no comments. The rational for the suggestion
> is also given in the text below but is basically that we did not have
> consensus for recording of document and application sharing just for
> video with reference to the content.
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Mar 2014 10:59:06 -0400

> Can you suggest a milestone that is more precise that we can get consensus on?

OK. I will think on it and come back with a new proposal.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Mar 2014 11:12:18 -0400

> Can you suggest a milestone that is more precise that we can get consensus on?

Does the following work for you?

   Protocol and metadata for using RTP media to record the sharing
   of applications, documents and screens.

	Thanks,
	Paul

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 20 Mar 2014 17:38:48 +0000

I would like to hear what others in the WG think.

Andy

> Sent: 20 March 2014 15:12
> To: Hutton, Andrew
> Cc: [email-masked]
> > The feedback we had during the IETF88 (Vancouver) meeting was that we
> could not extend SIPREC to generically cover "document & application"
> sharing as there is no standard to base this on.
> >
> >> want to be limited to that. While it needs discussion, I have in
> mind
> >> to
> >> These won't always be available, but if they are they would be
> useful
> >> to
> >> record.
> >>
> >>>> 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.
> >>>>
> >>>> regulatory and compliance reasons. In others, calls may be
> recorded
> >> for
> >>>> specification for a protocol that will manage delivery of media,
> in
> >> SIP

---

From: "Parthasarathi R" <[email-masked]>
Date: Fri, 21 Mar 2014 04:19:55 +0530

Hi Paul & all,

I understand that screen sharing shall be considered as a video stream. I'm
interested in knowing how RTP media is used for application and document
sharing.

Also, I'm interested in knowing whether RFC 5547 (A Session Description
Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer) will be
covered within MSRP recording deliverable or not.  

Thanks
Partha

> Sent: Thursday, March 20, 2014 11:09 PM
> Subject: Re: [siprec] SIPREC Milestone Update.
> 
> > >>> Please give feedback as to whether the milestone with reference
> to
> > >> RFC 4796 makes sense.
> > >>
> > >> And, if the presentation media includes audio as well as video,
> and
> > the
> > >> audio is distinct from the "room audio", we may want metadata to
> tie
> > >> the
> > >> Note that I've phrased the above as *may* because IMO this stuff
> is
> > all
> > >>>>   From that I have formed a proposal for a charter update which
> is
> > >> given
> > >>>> video session in which the content type (RFC 4796) formed part
> of
> > >> the
> > >>>> contribute can you confirm that you still intend to do so and
> that
> > >> this
> > >>>> floors. In some of these environments, all calls must be
> recorded
> > >> for
> > >>>> devices. The working group will determine requirements and
> produce
> > a
> > >>>> from an end-point that originates media, or that has access to
> it,
> > >> to a
> > >>>> standard protocol will reduce the complexity and cost of
> providing
> > >> such
> > >>>> recording services.
> > >>>>
> > >>>> and practices. This includes encryption, NAT traversal,
> operations
> > >> and

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Mar 2014 10:42:32 -0400

> interested in knowing how RTP media is used for application and document

My intent is to treat them exactly the same. And while the focus is on 
video, the sharing can also extend to audio and RTT.

> covered within MSRP recording deliverable or not.

I'd like to have discussion of that.

I think it makes sense to include it. The way that works, I think the 
SRS would have the option to accept or reject each file transfer, and 
might decide to refuse some or all of them. Also, in general for MSRP 
the SRS will have the option to select which content types it accepts. 
So I think the SRS has reasonable control to accept what it is prepared 
to record and reject things that are irrelevant or too costly to record.

	Thanks,
	Paul

---

From: "Parthasarathi R" <[email-masked]>
Date: Sun, 23 Mar 2014 16:11:23 +0530

Hi Paul,

Please read inline.

Thanks
Partha

> Sent: Friday, March 21, 2014 8:13 PM
> To: Parthasarathi R; 'Hutton, Andrew'; [email-masked]
<Partha> Agreed as it applies to some of the usecases wherein sharing is the
focus. But we need to consider the usecase wherein screen sharing as video
stream whereas the audio & RTT as the regular communication session, this
helps for debugging sort of scenario </Partha> 

> to record and reject things that are irrelevant or too costly to
<Partha> Thanks for the clarification about your point of view. I agree with
you that there should be option to select or reject in SRS. Please include
the initial text in your MSRP draft (draft-yan-siprec-msrp-recording) for
more discussion. </Partha>

> >>>>>>> limited to SIP based systems and that MSRP recording needs to
> be
> >>>>> added.
> >>>>>>>
> >>>>>>>>>> we will decide if we need charter language.  If your use
> case
> >>> is
> >>>>>>> not

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 23 Mar 2014 13:50:58 -0400

> helps for debugging sort of scenario </Partha>

Certainly. Each media stream may be for doc/app/screen sharing, or for 
normal interactive communications. There could be streams of any type 
for each in any given CS. It will be the task of metadata to distinguish 
the intent of each stream.

> more discussion. </Partha>

OK. In next version.

Note that the SRS is already free to select or reject any given media 
for recording - either be refusing to receive it, or by receiving it by 
not recording it. What we get here are more tools for selecting what to 
receive.

	Thanks,
	Paul

---

From: "Parthasarathi R" <[email-masked]>
Date: Mon, 24 Mar 2014 06:21:55 +0530

Hi Paul,

We are in the same page w.r.t RTP based doc/app/screen sharing and also, RFC
5547 usage within MSRP.

Thanks
Partha

> Sent: Sunday, March 23, 2014 11:21 PM
> >>>>>> The feedback we had during the IETF88 (Vancouver) meeting was
> that
> >>>> we
> >>>>>>>> "??? 2014 	Protocol and metadata for capturing the content
> (RFC
> >>>>>>> 4796) of the media stream".
> >>>>>>>>
> >>>>>>> is also given in the text below but is basically that we did
> not
> >>>>> have
> >>>>>>> consensus for recording of document and application sharing
> just
> >>>> for
> >>>>>>> IMO limiting this to RFC 4796 is too narrow for the milestone.
> It
> >>>>> may
> >>>>>>> perhaps audio) media streams, we *may* also want to say
> something
> >>>>> about
> >>>>>>> *how* this is done.
> >>>>>>>
> >>>>>>> subject to debate. But I would like it to be within the scope
> of
> >>>> the
> >>>>>>> milestone.
> >>>>>>>
> >>>>>>> The date for the milestone is another question. The December
> date
> >>>> is
> >>>>>>> probably a little optimistic, but I'd rather do that than have
> it
> >>>> be
> >>>>>>>>> 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
> >>>>>>>>> metadata then probably we would have consensus.  So I
> included
> >> a
> >>>>>>>>> generic mechanism to record media without the need to come
> back
> >>>> to
> >>>>>>>>> Please can provide comments and Paul and others who stated
> they
> >>>>>>> would
> >>>>>>>>> communications environments such as call centers and
> financial
> >>>>>>> trading
> >>>>>>>>> JUN 2014 	Submit protocol draft to IESG as Proposed
> Standard
> >>>>>>> RFC
> >>>>>>>>> ??? 2014 	Conference Recording Use Cases and Requirements
> to
> >>>>>>> IESG as
> >>>>>>>>> Informational RFC
> >>>>>>>>> ??? 2014 	Protocol and metadata for capturing the content
> (RFC
> >>>>>>> 4796)
> >>>>>>>>> of the media stream.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>>
> >>
> >>>>>>>>>> If so, better speak up, or IIUC we are going to treat the
> use
> >>>>> cases
> >>>>>>>>> we
> >>>>>>>>>>> The above is a little vague about the timing. Two weeks
> from
> >>>> the
> >>>>>>>>> end
> >>>>>>>>>> of
> >>>>>>>>>>> This is important because there was some desire to tighten
> up
> >>>>> the
> >>>>>>>>>> scope
> >>>>>>>>>>> additional media support. (Maybe we should rename the
> draft.)
> >>>>> And
> >>>>>>>>> it