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

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

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