Re: [siprec] FW: New VersionNotificationfor draft-portman-siprec-protocol-03

["Charles Eckel (eckelcu)" <[e-mail]>]

Please see inline.

> -----Original Message-----
> From: Henry Lum [mailto:[e-mail]]
> Sent: Friday, March 04, 2011 10:03 AM
> To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat)
> Cc: [e-mail]
> Subject: RE: [siprec] FW: New VersionNotificationfor
draft-portman-siprec-protocol-03
> 
> Inline.
> 
> > -----Original Message-----
> > From: Charles Eckel (eckelcu) [mailto:[e-mail]]
> > Sent: Friday, March 04, 2011 12:47 PM
> > To: Henry Lum; Paul Kyzivat (pkyzivat)
> > Cc: [e-mail]
> > Subject: RE: [siprec] FW: New VersionNotificationfor draft-portman-
> > siprec-protocol-03
> >
> > Hi Henry,
> >
> > Please see inline.
> >
> > > -----Original Message-----
> > > From: Henry Lum [mailto:[e-mail]]
> > > Sent: Friday, March 04, 2011 9:29 AM
> > > To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat)
> > > Cc: [e-mail]
> > > Subject: RE: [siprec] FW: New VersionNotificationfor
> > draft-portman-siprec-protocol-03
> > >
> > > Please see inline.
> > >
> > > > -----Original Message-----
> > > > From: Charles Eckel (eckelcu) [mailto:[e-mail]]
> > > > Sent: Thursday, March 03, 2011 4:55 PM
> > > > To: Henry Lum; Paul Kyzivat (pkyzivat)
> > > > Cc: [e-mail]
> > > > Subject: RE: [siprec] FW: New VersionNotificationfor
> draft-portman-
> > > > siprec-protocol-03
> > > >
> > > > 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.
> > > >
> > > [[hlum]] Okay - let's hear if there are supporters for INFO before
> > > making a change.
> >
> > Okay.
> >
> > > > 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.
> > >
> > > [[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.
> >
> > 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.
> 
> [[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?

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

> >
> > > >
> > > > 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?
> > >
> > > [[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.
> >
> > I see. This is really needed between the UA and the SRC, even if not
> > needed between the SRC and the SRS.
> >
> > > >
> > > > In section 6.3, recording preference, do we really need pause
and
> > > > 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."
> >
> > Here as well, it may not be needed between the SRC and the SRS, but
> > between a UA and a SRC, is that correct.
> >
> [[hlum]] Yes this mechanism is only for recording-aware UA in the CS.
>
> > Thanks,
> > Charles
> >
> > > > Cheers,
> > > > Charles
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail] [mailto:[e-mail]]
> On
> > > > Behalf Of Henry Lum
> > > > > Sent: Wednesday, March 02, 2011 8:45 AM
> > > > > To: Paul Kyzivat (pkyzivat)
> > > > > Cc: [e-mail]
> > > > > Subject: Re: [siprec] FW: New VersionNotificationfor
> > > > draft-portman-siprec-protocol-03
> > > > >
> > > > > 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
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Paul Kyzivat [mailto:[e-mail]]
> > > > > > Sent: Tuesday, March 01, 2011 8:10 PM
> > > > > > To: Henry Lum
> > > > > > Cc: [e-mail]
> > > > > > Subject: Re: [siprec] FW: New Version Notificationfor draft-
> > > > portman-
> > > > > > siprec-protocol-03
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 3/1/2011 2:32 PM, Henry Lum wrote:
> > > > > > > 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.
> > > > > >
> > > > > > 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
> > > > > >
> > > > > > > Regards,
> > > > > > > Henry
> > > > > > >
> > > > > > >> -----Original Message-----
> > > > > > >> From: [e-mail]
> > [mailto:[e-mail]]
> > > > On
> > > > > > >> Behalf Of Paul Kyzivat
> > > > > > >> Sent: Tuesday, March 01, 2011 1:50 PM
> > > > > > >> To: [e-mail]
> > > > > > >> Subject: Re: [siprec] FW: New Version Notificationfor
> > > > > draft-portman-
> > > > > > >> siprec-protocol-03
> > > > > > >>
> > > > > > >> 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:
> > > > > > >>> 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:[e-mail]]
> > > > > > >>> Sent: Tuesday, March 01, 2011 12:09 PM
> > > > > > >>> To: Henry Lum
> > > > > > >>> Cc: [e-mail]; [e-mail];
> > > > > > >> [e-mail]
> > > > > > >>> 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.
> > > > > > >>>
> > > > > > >>> _______________________________________________
> > > > > > >>> siprec mailing list
> > > > > > >>> [e-mail]
> > > > > > >>> https://www.ietf.org/mailman/listinfo/siprec
> > > > > > >>>
> > > > > > >> _______________________________________________
> > > > > > >> siprec mailing list
> > > > > > >> [e-mail]
> > > > > > >> https://www.ietf.org/mailman/listinfo/siprec
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > >
> ---------------------------------------------------------------------
> > > > > > ----------------------------------------------
> > > > > > > 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.
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
-----------------------------------------------------------------------
> > > > -
> > > > ------------------------------
> > > > > -------------
> > > > > 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.
> > > > >
> > > > > _______________________________________________
> > > > > siprec mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/siprec
> > >
> > >
> > >
> >
>
-----------------------------------------------------------------------
> > -
> > ------------------------------
> > > -------------
> > > 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.
> > >
> 
> 
>
------------------------------------------------------------------------
------------------------------
> -------------
> 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.
>