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

[Leon Portman <[e-mail]>]

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. 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.

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