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:leon.portman@gmail.com]
>Sent: Friday, March 16, 2012 11:51 PM
>To: Ravindran, Parthasarathi
>Cc: Leon Portman; siprec@ietf.org
>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"
><pravindran@sonusnet.com> 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:leon.portman@gmail.com]
>>> Sent: Friday, March 16, 2012 11:36 PM
>>> To: Ravindran, Parthasarathi
>>> Cc: Leon Portman; siprec@ietf.org
>>> 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"
>>> <pravindran@sonusnet.com> 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:leon.portman@gmail.com]
>>>>> Sent: Friday, March 16, 2012 11:14 PM
>>>>> To: Ravindran, Parthasarathi
>>>>> Cc: Leon Portman; siprec@ietf.org
>>>>> 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"
>>>>> <pravindran@sonusnet.com> 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: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On
>>>>>>> Behalf Of Leon Portman
>>>>>>> Sent: Tuesday, March 13, 2012 9:20 PM
>>>>>>> To: siprec@ietf.org
>>>>>>> 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: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On
>>>>>>> Behalf Of internet-drafts@ietf.org
>>>>>>> Sent: Monday, March 12, 2012 3:25 PM
>>>>>>> To: i-d-announce@ietf.org
>>>>>>> Cc: siprec@ietf.org
>>>>>>> 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
>>>>>>> siprec@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>>> _______________________________________________
>>>>>>> siprec mailing list
>>>>>>> siprec@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>> _______________________________________________
>>>>>> siprec mailing list
>>>>>> siprec@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>
>>