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

[Leon Portman <[e-mail]>]

Agree on both comments

Leon

-----Original Message-----
From: Hutton, Andrew [mailto:[e-mail]] 
Sent: Monday, March 19, 2012 4:17 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