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

Leon Portman <leon.portman@gmail.com> Fri, 16 March 2012 18:20 UTC

Return-Path: <leon.portman@gmail.com>
X-Original-To: siprec@ietfa.amsl.com
Delivered-To: siprec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A6D21E8059 for <siprec@ietfa.amsl.com>; Fri, 16 Mar 2012 11:20:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPXb4OxdUqPp for <siprec@ietfa.amsl.com>; Fri, 16 Mar 2012 11:20:55 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 150F921F862B for <siprec@ietf.org>; Fri, 16 Mar 2012 11:20:51 -0700 (PDT)
Received: by wibhq7 with SMTP id hq7so999952wib.13 for <siprec@ietf.org>; Fri, 16 Mar 2012 11:20:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=xZuLs06vwyLDKRB4GdiFHM5EgWPcI7IvKXKjIgdwBYM=; b=dPhaX+Z//rgnyKYZLjZAq2TUpskrq6c5xk98uEQ4jPF65RsaZtSRaDP07Hgtl0WSfY myTEWE1JnnZC/afw5/beZDVCgKmUPu0bzifbwN66AHmvDwh5CX2ZOjOPkMpFCafa6k/O A80uEKTtiN7koiBrCX6vOXSpuYhMjQPYBM+ZKb8hjr+8nLBx4WkNaqBR2TMkBQC2zUsP t5xbLYozGdUUNS25YsIrdXteZOKMNQBt4/0kP7FeRWVL+dLt9Y9CPcPbtpcI39jUgyaW DWB/iH8+yauiJ2Ab5amwmADMsCXJQAgsLCrPJHg5dndz5hbO6ltlbmS9EqvzguDu2Dyt UXig==
Received: by 10.180.103.35 with SMTP id ft3mr715811wib.0.1331922051210; Fri, 16 Mar 2012 11:20:51 -0700 (PDT)
Received: from [192.168.1.108] ([212.150.140.190]) by mx.google.com with ESMTPS id df3sm676909wib.1.2012.03.16.11.20.48 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Mar 2012 11:20:50 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1426\))
From: Leon Portman <leon.portman@gmail.com>
In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAF3@inba-mail01.sonusnet.com>
Date: Fri, 16 Mar 2012 20:20:49 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <96F77B6A-C42F-4C45-BF24-F6BF9CCAE026@gmail.com>
References: <20120312132433.19581.40959.idtracker@ietfa.amsl.com> <07465C1D981ABC41A344374066AE1A2C39DAF8C0A7@TLVMBX01.nice.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FCACA@inba-mail01.sonusnet.com> <AC091378-CAB3-4DA2-911F-D78D3DAC7D81@gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAD4@inba-mail01.sonusnet.com> <02E25602-BB51-4091-95E3-A5475AB4B85D@gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAF3@inba-mail01.sonusnet.com>
To: "Ravindran, Parthasarathi" <pravindran@sonusnet.com>
X-Mailer: Apple Mail (2.1426)
Cc: "siprec@ietf.org" <siprec@ietf.org>
Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/siprec>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Mar 2012 18:20:56 -0000

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