Subject: [siprec] FW: New Version Notification for draft-portman-siprec-protocol-03

From: "Henry Lum" <[email-masked]>
Date: Tue, 1 Mar 2011 09:13:11 -0800

A new version has been submitted to address the outstanding issues and include extensions for the new wording for REQ-017 and REQ-018.

https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/

Regards,
Henry

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Tuesday, March 01, 2011 12:09 PM
To: Henry Lum
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: New Version Notification for draft-portman-siprec-protocol-03 

A new version of I-D, draft-portman-siprec-protocol-03.txt has been successfully submitted by Henry Lum and posted to the IETF repository.

Filename:	 draft-portman-siprec-protocol
Revision:	 03
Title:		 The SIP-based Media Recording Protocol (SIPREC)
Creation_date:	 2011-03-01
WG ID:		 Independent Submission
Number_of_pages: 20

Abstract:
SIPREC Session Recording Protocol is used for establishing recording
session and reporting of the metadata of the communication session.

This document specifies the SIPREC Protocol (SIPREC).  SIPREC is used
between Session Recording Client (SRC) and Session Recording Server
(SRS).

The IETF Secretariat.

-------------------------------------------------------------------------------------------------------------------
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, 01 Mar 2011 13:50:13 -0500

Thanks Henry.

One comment/question:

Is there a reason to use an Info package for Requesting for metadata 
snapshot? Since we are already defining c-d recording-session and 
passing bodies in invite/update for it, is there a reason not to use the 
same mechanism to send error notifications/snapshop requests?

(I'm thinking just using a different content-type for this, and of 
course sending it from SRS to SRC.)

Also, we could consider permitting (not requiring) this in the responses 
to the messages containing metadata.

	Thanks,
	Paul

On 3/1/2011 12:13 PM, Henry Lum wrote:
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Henry Lum" <[email-masked]>
Date: Tue, 1 Mar 2011 11:32:59 -0800

When there is an UPDATE transaction collision, you will have to make
both SRC and SRS to wait a while before being able to send UPDATE again.
Since SRC is normally the side initiating the SIP dialog, it is the
owner of the Call-ID and will come second after the SRS has a chance to
resend the UPDATE. In that case, does the SRC keep the existing UPDATE
or send a new snapshot as requested by the SRS? The SRC also need to
keep track of metadata changes while waiting for the timer. I worry that
it will make the solution more complicated than just using an INFO for
snapshot request and minimize the collision problem.

Regards,
Henry

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: Tuesday, March 01, 2011 1:50 PM
> To: [email-masked]
> Subject: Re: [siprec] FW: New Version Notificationfor draft-portman-
> siprec-protocol-03
> 
> Thanks Henry.
> 
> One comment/question:
> 
> > A new version has been submitted to address the outstanding issues
> and include extensions for the new wording for REQ-017 and REQ-018.
> >
> > A new version of I-D, draft-portman-siprec-protocol-03.txt has been
> successfully submitted by Henry Lum and posted to the IETF repository.
> >
---------------------------------------------------------------------
> ----------------------------------------------
> > 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, 01 Mar 2011 20:09:48 -0500

> snapshot request and minimize the collision problem.

OK, collision on update is a *possibility*.
I guess the question is whether that justifies implementing an entirely 
different mechanism just for the rare error message.

I expect that the likelihood of collision is pretty slim, given that 
messages from the SRS to the SRC will be very infrequent, and if the 
message comes shortly after a metadata is received from the SRC, there 
may be little likelihood that the SRC will be sending more metadata so 
soon. And even if we don't use UPDATE for this, the SRC, like any UA, 
needs to be prepared to cope with a collision of this sort.

But I don't feel *too* strongly about this.

	Thanks,
	Paul

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 2 Mar 2011 08:44:38 -0800

I don't feel strongly too about using INFO so I am open to using UPDATE
if the group feels that it is okay for SRC/SRS to deal with the
consequences of UPDATE collision.

Henry

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, March 01, 2011 8:10 PM
> To: Henry Lum
> Cc: [email-masked]
> >> passing bodies in invite/update for it, is there a reason not to
use
> >> the
> >>> Subject: New Version Notification for draft-portman-siprec-
> protocol-
> >> 03
> >>>
> >>>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 3 Mar 2011 13:55:26 -0800

I think it is better to stick to using UPDATE and not introduce a need
to use INFO. I would also expect that using re-INVITE instead of UPDATE,
though not explicitly recommended, would work as well. What drives this
is the inclusion of the newly defined tags and the actual metadata.

Section 5 reads,
   
   The SRC must be able to accept re-INVITE from SRS with the updated
   SDP as part of the session timer mechanism.

What is the purpose of stating this? I agree the SRC needs to be able to
accept a re-INVITE with updated or non-updated SDP from the SRS. It also
needs to be able to receive an UPDATE with updated or non-updated SDP.
This appears to me to be independent of using session timer, and I do
not believe we are mandating support for session timer either.

In section 6.2, what does the "record" attribute and the defined
"indication" attribute give us that we do not already have using
sendonly and inactive, where off/pause maps to inactive and on maps to
sendonly?

In section 6.3, recording preference, do we really need pause and
resume? I am thinking record and norecord may be sufficient.

Cheers,
Charles

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Henry Lum
> Sent: Wednesday, March 02, 2011 8:45 AM
> To: Paul Kyzivat (pkyzivat)
> Cc: [email-masked]
> Subject: Re: [siprec] FW: New VersionNotificationfor
draft-portman-siprec-protocol-03
> > > owner of the Call-ID and will come second after the SRS has a
chance
> > to
> > > keep track of metadata changes while waiting for the timer. I
worry
> > that
> > >> refraining from acting, on any information contained in this
e-mail
> > is
------------------------------------------------------------------------
------------------------------
> -------------
> 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.

---

From: "Henry Lum" <[email-masked]>
Date: Fri, 4 Mar 2011 09:29:16 -0800

Please see inline.

> From: Charles Eckel (eckelcu) [mailto:[email-masked]]
> Sent: Thursday, March 03, 2011 4:55 PM
> To: Henry Lum; Paul Kyzivat (pkyzivat)
> Cc: [email-masked]
> Subject: RE: [siprec] FW: New VersionNotificationfor draft-portman-
> siprec-protocol-03
> 
[[hlum]] Okay - let's hear if there are supporters for INFO before
making a change.

> What is the purpose of stating this? 
> I agree the SRC needs to be able
> to

[[hlum]] Perhaps the wording may be a bit too explicit, but the
intention is that a recording session should use session timer since the
SRS never sends any media to the SRC and the SRC needs a way to tell
that the SRS is still around. I don't think session timer needs to be
mandated but I think it is recommended that we use it.

> sendonly and inactive, where off/pause maps to inactive and on maps to

[[hlum]] a=sendrev/sendonly/recvonly describes the directionality of the
actual media stream in the CS. What we want is an indication on the CS
media streams where recording is actually taking place or not, and that
should not involve changing the directionality of the actual media
stream.

On the recording session media streams, we do use a=sendrecv/sendonly to
indicate pause/resume. 

> resume? I am thinking record and norecord may be sufficient.
[[hlum]] The current consensus for the new wording of REQ-017 includes
pause and resume:

"REQ-zzz The mechanism MUST support a means for a recording-aware UA
involved in a CS to request during a session that the recording of the
CS should be started, paused, resumed or stopped, the honoring of such a
request being dependent on policy."

> > > > both SRC and SRS to wait a while before being able to send
UPDATE
> > > again.
> > > > or send a new snapshot as requested by the SRS? The SRC also
need
> > > > it will make the solution more complicated than just using an
> INFO
> > > for
> > > may be little likelihood that the SRC will be sending more
metadata
> so
> > > >>> This document specifies the SIPREC Protocol (SIPREC).  SIPREC
> is
> > > > used
> > > >> and/or its affiliated entities. Access by the intended
recipient
> > > only
> > > >> attachments and do not disclose the contents to any other
> person,
> > > use
> > > >> Copyright in this e-mail and any attachments belongs to
Alcatel-
> > > Lucent
e-mail
> > > and/or its affiliated entities.
-----------------------------------------------------------------------
> -
> contain

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 4 Mar 2011 09:46:35 -0800

Hi Henry,

Please see inline.

> From: Henry Lum [mailto:[email-masked]]
> Sent: Friday, March 04, 2011 9:29 AM
> To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat)
> Cc: [email-masked]
> Subject: RE: [siprec] FW: New VersionNotificationfor
> [[hlum]] Okay - let's hear if there are supporters for INFO before

Okay.

> mandated but I think it is recommended that we use it.

I am not a fan of that. I think session timer is optional. What is
mandatory in my opinion is that the SRS sends RTCP messages, and that
lets you know if is there and receiving the media. It also should do
something to make sure the RTP port does not get closed by a
firewall/NAT, and there are several mechanisms for that. That said, this
is not specific to SIPREC, so I do not think we need explicit
requirements, but if we are providing recommendations those are the one
I suggest providing.

> On the recording session media streams, we do use a=sendrecv/sendonly
to

I see. This is really needed between the UA and the SRC, even if not
needed between the SRC and the SRS.
 
> request being dependent on policy."

Here as well, it may not be needed between the SRC and the SRS, but
between a UA and a SRC, is that correct.

Thanks,
Charles

> > > > > When there is an UPDATE transaction collision, you will have
to
> > make
> > > > > Since SRC is normally the side initiating the SIP dialog, it
is
> > > > > resend the UPDATE. In that case, does the SRC keep the
existing
> > > > soon. And even if we don't use UPDATE for this, the SRC, like
any
> > UA,
> > > > >> From: [email-masked]
[mailto:[email-masked]]
> > On
> > > > >> (I'm thinking just using a different content-type for this,
and
> > of
> > > > >> Also, we could consider permitting (not requiring) this in
the
> > > > >> responses
> > > > >>> A new version of I-D, draft-portman-siprec-protocol-03.txt
has
> > > been
> > > > >> hereby excluded. If you are not the intended recipient,
please
> > > > notify
person,
> > Alcatel-Lucent

---

From: "Henry Lum" <[email-masked]>
Date: Fri, 4 Mar 2011 10:02:44 -0800

Inline.

> Sent: Friday, March 04, 2011 12:47 PM
draft-portman-
> > > accept a re-INVITE with updated or non-updated SDP from the SRS.
It
> > > also

[[hlum]] Agreed that this problem is not specific to SIPREC. The SRS
does not send RTP to the SRC so I don't think it matters when that RTP
port gets closed, but it makes sense to for SRS to send RTCP messages to
the SRC to acknowledge receipt of recorded media. Do we need to mandate
this?

> > > sendonly and inactive, where off/pause maps to inactive and on
maps
> > On the recording session media streams, we do use
a=sendrecv/sendonly
> > CS should be started, paused, resumed or stopped, the honoring of
> such
> a
[[hlum]] Yes this mechanism is only for recording-aware UA in the CS.

> > > > > I expect that the likelihood of collision is pretty slim,
given
> > > that
> > > > > messages from the SRS to the SRC will be very infrequent, and
> if
> > > the
> > > > > message comes shortly after a metadata is received from the
> SRC,
> > > there
> > > > > >> snapshot? Since we are already defining c-d recording-
> session
> > > and
> > > > > >> passing bodies in invite/update for it, is there a reason
> not
> > to
> > > > use
> > > > > >> the
> > > > > >>> A new version has been submitted to address the
outstanding
> > > issues
> > > > > >>> between Session Recording Client (SRC) and Session
> Recording
> > > > Server
> > > > > >>> (SRS).
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>> The IETF Secretariat.
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >
> > > >
> >
> > > > > >> the sender immediately, destroy the original transmission
> and
> > > its
> > > > contents to any other person, use it for any purpose, or store
or
> > > copy

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 4 Mar 2011 10:15:00 -0800

Please see inline.

> Sent: Friday, March 04, 2011 10:03 AM
> > > > I think it is better to stick to using UPDATE and not introduce
a
> > > > though not explicitly recommended, would work as well. What
drives
> > > this
> > > > needs to be able to receive an UPDATE with updated or
non-updated
> > SDP.
> > > > This appears to me to be independent of using session timer, and
I
> > do
> > > intention is that a recording session should use session timer
since
> the SRC to acknowledge receipt of recorded media. Do we need to
mandate

RFC 3550 already mandates RTCP. We could reference
draft-marjou-behave-app-rtp-keepalive and RFC 5761, but I do not think
we need to mandate this.

Cheers,
Charles

> > > [[hlum]] a=sendrev/sendonly/recvonly describes the directionality
of
> > the
> > > actual media stream in the CS. What we want is an indication on
the
> > CS
> > > > > I don't feel strongly too about using INFO so I am open to
using
> > > > > > > owner of the Call-ID and will come second after the SRS
has
> > > > > > > keep track of metadata changes while waiting for the
timer.
> I
> > > > > > I guess the question is whether that justifies implementing
an
> > > > > entirely
> > > > > > >> Is there a reason to use an Info package for Requesting
for
> > > > > > >> and include extensions for the new wording for REQ-017
and
> > > > REQ-018.
> > > > > > >> successfully submitted by Henry Lum and posted to the
IETF
> > > > > > repository.
> > > > > > >>> SIPREC Session Recording Protocol is used for
establishing
> > > > > > recording
> > > > > > >>> session and reporting of the metadata of the
communication
> > > > > session.
> > > > > > >>> CONFIDENTIALITY NOTICE: This e-mail and any files
attached
> > may
> > > > > > >> is authorized. Any liability arising from any party
acting,
> > > > > > >> it for any purpose, or store or copy the information in
any
> > > > medium.
please
and
Alcatel-

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Mar 2011 13:18:11 -0500

> mandated but I think it is recommended that we use it.

I will repeat the mantra I have been issuing periodically for years:

Session timer is supported by UAs for the benefit of *proxies*!

UAs don't *need* session timer - they can independently send a request 
any time they wonder if the other end is still live.

	Thanks,
	Paul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Sun, 6 Mar 2011 23:39:51 +0530

Hi Henry,
 
I agree with Paul & Charles for INFO vs UPDATE or RE-INVITE without SDP. My general comments and doubt are as follows:

1) Fig 2 Step 5 indicates callid. Pls elaborate what is the callid represented here?

2) Sec 4.3,  "The metadata snapshot request will be provided as an INFO

   package [RFC6086] and sent as mid-dialog messages within the

   recording session by the SRS." it shall be UPDATE or RE-INVITE without SDP with request for complete metadata.

3) Sec 4.3 last para: "however, it is

   envisioned that a link with a URI can be provided in the recording

   session INVITE message so that the SRS can access the session

   metadata via the URI provided that the SRS supports the type of URI."

   Any new mechanism will be introduced in RS to pass this link?

4) Sec 5 last para: During mid-dialog transaction in Recording session (dialog) between SRC and SRS, SRC and SRC SHALL support all SIP mid-dialog behavior between two UA. IOW, SRS may be sending RE-INVITE/UDPATE for media attributes change, session timer or any other reason.

5) Update Sec 5.3.1 as per the comment 1 wherein Re-INVITE/UPDATE shall be used to request new metadata snapshot

6) As earlier discussed, pls include the possible error code in the draft.

Doubt:

1) Fig 3 which may leads to UA A moves out of the conference right?

Please read inline for more comments

Thanks

Partha

________________________________

From: [email-masked] on behalf of Charles Eckel (eckelcu)
Sent: Fri 3/4/2011 11:45 PM
To: Henry Lum; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: Re: [siprec] FW: NewVersionNotificationfor draft-portman-siprec-protocol-03

Please see inline.

a
drives
non-updated
I
since

Cheers,
Charles

<Partha> SRS & SRC MUST mid-dialog behavior of RFC 3261 which includes codec change, media change, session timer (optional)  </Partha>

of
the
using
has
timer.
an
for
and
IETF
establishing
communication
attached
acting,
any
please
and
Alcatel-