Re: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt

["Hutton, Andrew" <[e-mail]>]

Hi Partha,

I am not sure I understand your concern. The minimum an SRS may know is that it needs to initiate a RS with certain SRC's but it does not necessarily need to know exactly what is going to be recorded. The SRC will tell the SRS what is being recorded using SDP and metadata.


Regards
Andy





> -----Original Message-----
> From: Ravindran, Parthasarathi [mailto:[e-mail]]
> Sent: 19 March 2012 14:26
> To: Hutton, Andrew; Leon Portman; Leon Portman
> Cc: [e-mail]
> Subject: RE: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt
>
> Andy,
>
> Could you please explain how SRC policy based recording will not cause
> issue in SRS as SRS will not know what is going to be recorded when
> initiating RS INVITE.
>
> Based on my experience, I noticed that SRC policy based SRS-initiated
> callflow cause more issue to SRC as well.
>
> Thanks
> Partha
>
> >-----Original Message-----
> >From: Hutton, Andrew [mailto:[e-mail]]
> >Sent: Monday, March 19, 2012 7:47 PM
> >To: Leon Portman; Ravindran, Parthasarathi; Leon Portman
> >Cc: [e-mail]
> >Subject: RE: [siprec] I-D Action: draft-ietf-siprec-architecture-
> 04.txt
> >
> >See below.
> >
> >Regards
> >Andy
> >
> >> -----Original Message-----
> >> From: Leon Portman [mailto:[e-mail]]
> >> Sent: 19 March 2012 14:10
> >> To: Ravindran, Parthasarathi; Hutton, Andrew; Leon Portman
> >> Cc: [e-mail]
> >> Subject: RE: [siprec] I-D Action:
> >> draft-ietf-siprec-architecture-04.txt
> >>
> >> Actually these are two separate issues, one is how to identify the
> >> communication session, and second how to indicate it in RS invite
> >> (FROM SRS to SRC).
> >> Back to Andy comment, even for persistent use case, SRS will send
> re-
> >> invite with some CS identifier so we need to have such mechanism.
> >
> >[AndyH] - I assume this should be "SRS MAY send re-invite with some CS
> >Identifier..." because of course it can be the SRC that makes that
> >decision based on policy.
> >
> >>My
> >> understanding from the below thread was to add the policy mentioning
> >>and not just to completely remove the mechanism mentioning. I am ok
> >>with both options.
> >> I will remove Join example it in the next update.
> >>
> >
> >[AndyH] - I think we should remove the mechanism from the architecture
> >draft the "Join" example was there to promote discussion even before
> we
> >had a protocol draft and I think should now be removed.
> >
> >>
> >> Regards
> >>
> >> Leon
> >>
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On
> >> Behalf Of Ravindran, Parthasarathi
> >> Sent: Monday, March 19, 2012 4:01 PM
> >> To: Hutton, Andrew; Leon Portman
> >> Cc: [e-mail]
> >> Subject: Re: [siprec] I-D Action:
> >> draft-ietf-siprec-architecture-04.txt
> >>
> >> Hi Andy,
> >>
> >> As I mentioned in the below mail, the policy of SRC should not
> decide
> >> what recording has to be started rather it has to be clearly
> mentioned
> >> by SRS and it will leads to interop issue as SRS has to expect
> >> recording based on different SRC implementation.
> >>
> >> In case CS id is not generic enough for SRS-initiated callflow. Let
> us
> >> work for the list of possible standard mechanism required
> >>
> >> 1) Communication Session-id
> >> 2) participant
> >> 3) stream???
> >>
> >> I still think that the exact SRS-initiated recording mechanism has
> to
> >> be mentioned in the protocol draft rather than in the architecture
> >> document.
> >>
> >> Thanks
> >> Partha
> >>
> >> >-----Original Message-----
> >> >From: Hutton, Andrew [mailto:[e-mail]]
> >> >Sent: Monday, March 19, 2012 7:20 PM
> >> >To: Ravindran, Parthasarathi; Leon Portman
> >> >Cc: [e-mail]
> >> >Subject: RE: [siprec] I-D Action: draft-ietf-siprec-architecture-
> >> 04.txt
> >> >
> >> >Hi Leon,
> >> >
> >> >I expected the bullet in section 3.2.2 stating "Identify the
> session
> >> >that is to be recorded - Possibly using the Join header" to be
> >> >removed in this latest update. The issue was raised by Gonzalo and
> in
> >> >my response to those on the mailing list. (See
> >> >http://www.ietf.org/mail-
> archive/web/siprec/current/msg03125.html).
> >> >
> >> >In previous discussion I thought we had agreed at least in some
> >> >scenarios there was no need to define such a mechanism as it would
> be
> >> >up to policy at the SRC and for example in the persistent recording
> >> >case there may not even be a CS at the time the RS is established.
> >> >
> >> >Regards
> >> >Andy
> >> >
> >> >
> >> >
> >> >
> >> >> -----Original Message-----
> >> >> From: [e-mail] [mailto:[e-mail]] On
> >> >> Behalf Of Ravindran, Parthasarathi
> >> >> Sent: 16 March 2012 18:39
> >> >> To: Leon Portman
> >> >> Cc: [e-mail]
> >> >> Subject: Re: [siprec] I-D Action:
> >> >> draft-ietf-siprec-architecture-04.txt
> >> >>
> >> >> Leon,
> >> >>
> >> >> I agree with you. Let architecture document mentions only that
> the
> >> >> mechanism is required to identify the communication session in
> SRS-
> >> >> initiated callflow and exact mechanism will be defined in
> protocol
> >> >> draft.
> >> >>
> >> >> Thanks
> >> >> Partha
> >> >>
> >> >> >-----Original Message-----
> >> >> >From: Leon Portman [mailto:[e-mail]]
> >> >> >Sent: Friday, March 16, 2012 11:51 PM
> >> >> >To: Ravindran, Parthasarathi
> >> >> >Cc: Leon Portman; [e-mail]
> >> >> >Subject: Re: [siprec] I-D Action: draft-ietf-siprec-
> architecture-
> >> >> 04.txt
> >> >> >
> >> >> >The main question then, if it will be required to be defined in
> >> >> >the protocol draft and we can keep architecture draft at high
> >> >> >level in
> >> >> order
> >> >> >to move forward
> >> >> >
> >> >> >Leon
> >> >> >
> >> >> >On Mar 16, 2012, at 8:16 PM, "Ravindran, Parthasarathi"
> >> >> ><[e-mail]> wrote:
> >> >> >
> >> >> >> Leon,
> >> >> >>
> >> >> >> I agree with you that session-id solves the reported problem.
> >> >> >>
> >> >> >> As you might know, Session id IETF WG namely INSIPID is in the
> >> >> >> very
> >> >> >early stage and number of drafts under discussion for IETF-83
> are
> >> >> listed
> >> >> >in http://www.ietf.org/mail-
> >> >archive/web/insipid/current/msg00005.html.
> >> >> >IMO, creating session-id dependency will delay SIPREC
> deliverable.
> >> >> >We will brainstorm more to find some way without session-id if
> >> exists.
> >> >> >>
> >> >> >> Thanks
> >> >> >> Partha
> >> >> >>
> >> >> >>> -----Original Message-----
> >> >> >>> From: Leon Portman [mailto:[e-mail]]
> >> >> >>> Sent: Friday, March 16, 2012 11:36 PM
> >> >> >>> To: Ravindran, Parthasarathi
> >> >> >>> Cc: Leon Portman; [e-mail]
> >> >> >>> Subject: Re: [siprec] I-D Action:
> >> >> >>> draft-ietf-siprec-architecture-04.txt
> >> >> >>>
> >> >> >>> Partha,
> >> >> >>>
> >> >> >>> I completely agree with you. Session identification is one of
> >> the
> >> >> >>> main pain points today. May be Global session ID work will
> help
> >> >> here?
> >> >> >>> http://tools.ietf.org/html/draft-kaplan-dispatch-session-id-
> 01
> >> >> >>>
> >> >> >>> Leon
> >> >> >>>
> >> >> >>> On Mar 16, 2012, at 7:59 PM, "Ravindran, Parthasarathi"
> >> >> >>> <[e-mail]> wrote:
> >> >> >>>
> >> >> >>>> Leon,
> >> >> >>>>
> >> >> >>>> I agree with you that it is the way proprietary SIP
> recording
> >> >> works
> >> >> >>> today. For each SRS initiated callflow, unique-id of a
> session
> >> is
> >> >> >>> generated by PBX driven or CTI, SRC is forced to develop
> >> multiple
> >> >> >>> solutions accordingly as there is a lack of standard
> mechanism.
> >> >> >>> I have concern because SRS initiated without any specific
> >> >> >>> identification continue the same trend of today's proprietary
> >> >> >>> recording solution. I wish to see some well-defined protocol
> >> >> >>> mechanism from SRS to SRC to identity the session which has
> to
> >> >> >>> recorded. Please let me know your opinion.
> >> >> >>>>
> >> >> >>>> As you have listed number of mechanism, I'm fine in case we
> >> >> >>>> nailed
> >> >> >>> down to one of the mechanism as standard in the worst case.
> >> >> >>>>
> >> >> >>>> Thanks
> >> >> >>>> Partha
> >> >> >>>>
> >> >> >>>>> -----Original Message-----
> >> >> >>>>> From: Leon Portman [mailto:[e-mail]]
> >> >> >>>>> Sent: Friday, March 16, 2012 11:14 PM
> >> >> >>>>> To: Ravindran, Parthasarathi
> >> >> >>>>> Cc: Leon Portman; [e-mail]
> >> >> >>>>> Subject: Re: [siprec] I-D Action:
> >> >> >>>>> draft-ietf-siprec-architecture-04.txt
> >> >> >>>>>
> >> >> >>>>> Partha Hi
> >> >> >>>>>
> >> >> >>>>> The ways of identification of CS to be recorded for  SRS
> >> >> initiated
> >> >> >>>>> flows are very dependent on actual SRC implementation.
> >> >> >>>>> For example, if SRC is PBX, it can be even CTI call id,
> >> >> >>>>> participants ids, DNS name of end point etc.
> >> >> >>>>>
> >> >> >>>>> For gateways it can be IP and PORT of RTP stream for
> example.
> >> >> >>>>>
> >> >> >>>>> This what i meant that it is very defendant on SRC and on
> the
> >> >> >>>>> way how SRS knows about CSs.
> >> >> >>>>>
> >> >> >>>>> Regards
> >> >> >>>>>
> >> >> >>>>> Leon
> >> >> >>>>>
> >> >> >>>>> On Mar 14, 2012, at 4:12 PM, "Ravindran, Parthasarathi"
> >> >> >>>>> <[e-mail]> wrote:
> >> >> >>>>>
> >> >> >>>>>> Leon,
> >> >> >>>>>>
> >> >> >>>>>> Could you please explain in detail about Sec 3.2.2 update
> >> >> >>>>>>
> >> >> >>>>>> "   o  The actual mechanism of the identification is
> depends
> >> on
> >> >> >SRC
> >> >> >>>>>>    policy."
> >> >> >>>>>>
> >> >> >>>>>> Thanks
> >> >> >>>>>> partha
> >> >> >>>>>>
> >> >> >>>>>>> -----Original Message-----
> >> >> >>>>>>> From: [e-mail]
> >> >> >>>>>>> [mailto:[e-mail]]
> >> >> On
> >> >> >>>>>>> Behalf Of Leon Portman
> >> >> >>>>>>> Sent: Tuesday, March 13, 2012 9:20 PM
> >> >> >>>>>>> To: [e-mail]
> >> >> >>>>>>> Subject: Re: [siprec] I-D Action:
> >> >> >>>>>>> draft-ietf-siprec-architecture-04.txt
> >> >> >>>>>>>
> >> >> >>>>>>> Main changes. They are mainly consist from Gonzalo and
> >> >> >>>>>>> other mailing lists comments.
> >> >> >>>>>>>
> >> >> >>>>>>> 1. Definitions: Adding recording unaware UA definition
> and
> >> >> fixing
> >> >> >>>>>>> some other definitions 2. Consistent abbreviation usage
> in
> >> >> >>>>>>> the
> >> >> >>>>> document 3.
> >> >> >>>>>>> Figures fixes 4. Adding policy mentions in Endpoint as
> SRC
> >> 5.
> >> >> >>>>>>> Removing WEBRTC mentions 6. Adding more descriptions in
> SRS
> >> >> >>>>>>> initiated flows 7.Adding support for RS without metadata
> >> >> >>>>>>>
> >> >> >>>>>>> There are some small typo mistakes in v04. I have already
> >> >> >>>>>>> fixed them and will update in next version
> >> >> >>>>>>>
> >> >> >>>>>>> Regards
> >> >> >>>>>>>
> >> >> >>>>>>> Leon
> >> >> >>>>>>>
> >> >> >>>>>>> -----Original Message-----
> >> >> >>>>>>> From: [e-mail]
> >> >> >>>>>>> [mailto:[e-mail]]
> >> >> On
> >> >> >>>>>>> Behalf Of [e-mail]
> >> >> >>>>>>> Sent: Monday, March 12, 2012 3:25 PM
> >> >> >>>>>>> To: [e-mail]
> >> >> >>>>>>> Cc: [e-mail]
> >> >> >>>>>>> Subject: [siprec] I-D Action:
> >> >> >>>>>>> draft-ietf-siprec-architecture-04.txt
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>> A New Internet-Draft is available from the on-line
> >> >> >>>>>>> Internet-Drafts directories. This draft is a work item of
> >> the
> >> >> SIP
> >> >> >>>>>>> Recording Working Group of the IETF.
> >> >> >>>>>>>
> >> >> >>>>>>>         Title           : An Architecture for Media Recording
> >using
> >> >> >the
> >> >> >>>>>>> Session Initiation Protocol
> >> >> >>>>>>>         Author(s)       : Andrew Hutton
> >> >> >>>>>>>                       Leon Portman
> >> >> >>>>>>>                       Rajnish Jain
> >> >> >>>>>>>                       Ken Rehor
> >> >> >>>>>>>         Filename        : draft-ietf-siprec-architecture-
> >04.txt
> >> >> >>>>>>>         Pages           : 16
> >> >> >>>>>>>         Date            : 2012-03-12
> >> >> >>>>>>>
> >> >> >>>>>>> Session recording is a critical requirement in many
> >> >> >>>>>>> communications environments such as call centers and
> >> >> >>>>>>> financial trading.  In some of these environments, all
> >> >> >>>>>>> calls must be recorded for regulatory, compliance, and
> >> >> >>>>>>> consumer protection reasons.  Recording of a session is
> >> >> >>>>>>> typically performed by sending a copy of a media stream
> to
> >> >> >>>>>>> a recording device.  This document describes
> architectures
> >> >> >>>>>>> for deploying session
> >> >> recording
> >> >> >>>>>>> solutions in an environment which is based on the Session
> >> >> >Initiation Protocol (SIP).
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>> A URL for this Internet-Draft is:
> >> >> >>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-siprec-
> >> >> architectur
> >> >> >>>>>>> e-
> >> >> >>>>>>> 04.txt
> >> >> >>>>>>>
> >> >> >>>>>>> Internet-Drafts are also available by anonymous FTP at:
> >> >> >>>>>>> ftp://ftp.ietf.org/internet-drafts/
> >> >> >>>>>>>
> >> >> >>>>>>> This Internet-Draft can be retrieved at:
> >> >> >>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-
> >> >> architecture
> >> >> >>>>>>> -
> >> >> >>> 04.
> >> >> >>>>>>> txt
> >> >> >>>>>>>
> >> >> >>>>>>> _______________________________________________
> >> >> >>>>>>> siprec mailing list
> >> >> >>>>>>> [e-mail]
> >> >> >>>>>>> https://www.ietf.org/mailman/listinfo/siprec
> >> >> >>>>>>> _______________________________________________
> >> >> >>>>>>> siprec mailing list
> >> >> >>>>>>> [e-mail]
> >> >> >>>>>>> https://www.ietf.org/mailman/listinfo/siprec
> >> >> >>>>>> _______________________________________________
> >> >> >>>>>> siprec mailing list
> >> >> >>>>>> [e-mail]
> >> >> >>>>>> https://www.ietf.org/mailman/listinfo/siprec
> >> >> >>>>
> >> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> siprec mailing list
> >> >> [e-mail]
> >> >> https://www.ietf.org/mailman/listinfo/siprec
> >> _______________________________________________
> >> siprec mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/siprec