Re: [siprec] FW: NewVersionNotificationfor draft-portman-siprec-protocol-03

["Parthasarathi R (partr)" <[e-mail]>]

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: [e-mail] on behalf of Charles Eckel (eckelcu)
Sent: Fri 3/4/2011 11:45 PM
To: Henry Lum; Paul Kyzivat (pkyzivat)
Cc: [e-mail]
Subject: Re: [siprec] FW: NewVersionNotificationfor draft-portman-siprec-protocol-03



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

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

> >
> > > >
> > > > 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.
>
_______________________________________________
siprec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/siprec