From partr@cisco.com Mon Jan 3 01:23:06 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BB6728C0FD for ; Mon, 3 Jan 2011 01:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[AWL=0.560, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRLCVEpZC4+Q for ; Mon, 3 Jan 2011 01:23:05 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 540B228C0FA for ; Mon, 3 Jan 2011 01:23:04 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAckIU2Q/khLgWdsb2JhbACCKKIKFQEBFiIkok6YO4VKBIRjiUQ X-IronPort-AV: E=Sophos;i="4.60,266,1291593600"; d="scan'208,217";a="16182849" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 03 Jan 2011 09:25:02 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p039NnFC012970 for ; Mon, 3 Jan 2011 09:25:01 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Jan 2011 14:54:10 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBAB27.FA5C0B33" Date: Mon, 3 Jan 2011 14:54:09 +0530 Message-ID: In-Reply-To: <7744FE52C78D944587F03773EB45146109139DEE@xmb-sjc-22e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] draft-ietf-siprec-req-06 posted Thread-Index: AcupemC/6QmwULhdT5CrRoSmufArYQBrQkUQ References: <7744FE52C78D944587F03773EB45146109139DEE@xmb-sjc-22e.amer.cisco.com> From: "Parthasarathi R (partr)" To: "Ken Rehor (krehor)" , X-OriginalArrivalTime: 03 Jan 2011 09:24:10.0409 (UTC) FILETIME=[FA72C190:01CBAB27] Subject: Re: [siprec] draft-ietf-siprec-req-06 posted X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 09:23:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBAB27.FA5C0B33 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ken and all, =20 During the last interim meeting, it was decided to put the "forced deletion" attribute in the appdata of Metadata model instead of including in the model. Cancel and discard recording from SRC is considered as policy mechanism passing to SRS. If so, the following requirements has to be removed from SIPREC requirement: =20 o REQ-015: The mechanism MUST support a means to cancel and discard the recording and associated metadata for a CS. o REQ-016: The mechanism MUST support a means to cancel and discard the recording but not the associated metadata for a CS. Please let me know your opinion on the same. =20 Thanks Partha ________________________________ From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ken Rehor (krehor) Sent: Saturday, January 01, 2011 11:39 AM To: siprec@ietf.org Subject: [siprec] draft-ietf-siprec-req-06 posted - ietf-siprec-req-06 posted http://www.ietf.org/internet-drafts/draft-ietf-siprec-req-06.txt - tracker item #61 closed - Draft and change log attached =20 Happy New Year! =20 Ken =20 =20 For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 ------_=_NextPart_001_01CBAB27.FA5C0B33 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ken and all,
 
During the last interim meeting, it was decided to = put the=20 "forced deletion" attribute in the appdata of Metadata model instead of=20 including in the model. Cancel and discard recording from SRC = is=20 considered as policy mechanism passing to SRS. If so, the following = requirements has to be removed from SIPREC = requirement:
 
   o REQ-015:=20 The mechanism MUST support a means to cancel and discard
   = the=20 recording and associated metadata for a CS.

   o = REQ-016: The=20 mechanism MUST support a means to cancel and discard
   the = recording but not the associated metadata for a CS.
Please let me know your opinion on the=20 same.
 
Thanks
Partha
From: siprec-bounces@ietf.org=20 [mailto:siprec-bounces@ietf.org] On Behalf Of Ken Rehor=20 (krehor)
Sent: Saturday, January 01, 2011 11:39 = AM
To:=20 siprec@ietf.org
Subject: [siprec] draft-ietf-siprec-req-06=20 posted

-         =20 ietf-siprec-req-06 posted    http://www.ietf.org/internet-drafts/draft-ietf-siprec-req-06.txt

-         =20 tracker item #61 closed

-         =20 Draft and change log attached

 

Happy New Year!

 

Ken

 

 

For = corporate legal=20 information go=20 to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 

------_=_NextPart_001_01CBAB27.FA5C0B33-- From rmohanr@cisco.com Mon Jan 3 01:30:49 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D009528C105 for ; Mon, 3 Jan 2011 01:30:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.198 X-Spam-Level: X-Spam-Status: No, score=-10.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43rM9t3RKKWy for ; Mon, 3 Jan 2011 01:30:47 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 7A96228C102 for ; Mon, 3 Jan 2011 01:30:46 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAF4mIU2Q/khMgWdsb2JhbACCKKIKFQEBFiIkolaYO4VKBIRjiUQ X-IronPort-AV: E=Sophos;i="4.60,266,1291593600"; d="scan'208,217";a="16183360" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 03 Jan 2011 09:32:53 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p039Whhu020522; Mon, 3 Jan 2011 09:32:52 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Jan 2011 15:02:45 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBAB29.2D025C05" Date: Mon, 3 Jan 2011 15:02:43 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD04CCC1F7@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD04CCB7EE@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] SIPREC Metadata Model: Soliciting use cases for CSs to beconcurrently associated (different views) with multiple CS-Groups Thread-Index: AcuhD3COLexGMLuuRnS0V5zAt3X03gKGVMSg References: <35BCE99A477D6A4986FB2216D8CF2CFD04CCB7EE@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: , "De Villiers de Wet" X-OriginalArrivalTime: 03 Jan 2011 09:32:45.0119 (UTC) FILETIME=[2D3D44F0:01CBAB29] Subject: Re: [siprec] SIPREC Metadata Model: Soliciting use cases for CSs to beconcurrently associated (different views) with multiple CS-Groups X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 09:30:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBAB29.2D025C05 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have not heard any use cases for CSs to be concurrently associated with multiple CS-Groups. Please let me have the use cases if any before Jan 5th 2011. Otherwise I will close this open item of metadata and retain the association as described in draft-ram-siprec-metadata-02. =20 Regards, Ram =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) Sent: Tuesday, December 21, 2010 6:33 PM To: siprec@ietf.org; De Villiers de Wet Subject: [siprec] SIPREC Metadata Model: Soliciting use cases for CSs to beconcurrently associated (different views) with multiple CS-Groups =20 Hi All, =20 During the SIPREC IETF virtual interim meeting on Dec 16th 2010, it was unclear on use cases for a Communication Session (CS) to be associated with multiple CS-Groups concurrently.=20 =20 Can someone suggest some use cases by which we can evaluate if this association is needed ? =20 In some of the earlier discussions [ with De Villiers de Wet] it was seen that we may need different groupings (from the perspective of customer, from the perspective of Agent or supervisor). Storing these different views(groupings) may be useful at SRS as there may be applications that may query for one view(a customer's view or agents view or supervisors view).=20 However it was later agreed that these views can be derived by SRS by using the existing SIPREC metadata model ( from participants) even without having a Communication Session (CS) to be associated with multiple CS-Groups concurrently. =20 If there are no compelling use cases, I will close this open item and have the association as it is in the current model(draft-ram-siprec-metadata-02) =20 Regards, Ram =20 =20 =20 =20 ------_=_NextPart_001_01CBAB29.2D025C05 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have not heard any use cases for CSs to be = concurrently associated with multiple CS-Groups.  Please let me = have the use cases  if any before Jan 5th = 2011.

Otherwise I will close this open item of = metadata and retain the association as described in = draft-ram-siprec-metadata-02.

 

Regards,

Ram

 

From:= = siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Ram Mohan R (rmohanr)
Sent: Tuesday, December 21, 2010 = 6:33 PM
To: siprec@ietf.org; De Villiers de = Wet
Subject: [siprec] SIPREC Metadata Model: Soliciting use = cases for CSs to beconcurrently associated (different views) with = multiple CS-Groups

 

Hi = All,

 

During the SIPREC IETF virtual interim meeting on Dec = 16th 2010, it was unclear on use cases for  a = Communication Session (CS) to be associated with multiple CS-Groups = concurrently.

 

Can someone = suggest some use cases by which we can evaluate if this association is = needed ?

 

In some of the earlier discussions [  with De = Villiers de Wet] it was seen that we may need different groupings (from = the perspective of customer, from the perspective of Agent or = supervisor). Storing these different views(groupings) may be useful at = SRS as there may be applications that  may query for one view(a = customer's view or agents view or  supervisors view). =

However it was later agreed that = these views can be derived by SRS by using the existing  SIPREC = metadata model  ( from participants) even without having a = Communication Session (CS) to be associated with multiple CS-Groups = concurrently.

 

If there are no compelling use cases, I will close = this open item and have the association as it is in the current = model(draft-ram-siprec-metadata-02)

 

Regards,

Ram

 

 

 

 

------_=_NextPart_001_01CBAB29.2D025C05-- From partr@cisco.com Mon Jan 3 03:51:37 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A13793A69D4 for ; Mon, 3 Jan 2011 03:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.055 X-Spam-Level: X-Spam-Status: No, score=-10.055 tagged_above=-999 required=5 tests=[AWL=0.543, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3k+9WrGM9-v2 for ; Mon, 3 Jan 2011 03:51:36 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 0EC013A6956 for ; Mon, 3 Jan 2011 03:51:36 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao4FAClIIU1AaMHG/2dsb2JhbACWFo4dc6I1mEGFSgSEY4lE X-IronPort-AV: E=Sophos;i="4.60,266,1291593600"; d="scan'208,217";a="309564645" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-5.cisco.com with ESMTP; 03 Jan 2011 11:53:35 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p03Bqprj027105 for ; Mon, 3 Jan 2011 11:53:29 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Jan 2011 17:23:26 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBAB3C.D46FCA83" Date: Mon, 3 Jan 2011 17:23:25 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Participant role parameter in Metadata model Thread-Index: AcurPNRLSEZshgfrQy2dByCWghDbyg== From: "Parthasarathi R (partr)" To: X-OriginalArrivalTime: 03 Jan 2011 11:53:26.0368 (UTC) FILETIME=[D49DA600:01CBAB3C] Subject: [siprec] Participant role parameter in Metadata model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 11:51:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBAB3C.D46FCA83 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 >From the current metadata parameters, it is not possible for SRS to deduce whether the participant is acting as "uac" or "uas" for a given transaction in CS but SRC is aware of this information in most of the scenarios. Participant role information in CS will be lost as RS is not carry this information as part of metadata. IMO, it is better to add this information as participant role with value as "uac" or "uas" or "don't know" in the metadata.=20 =20 This information helps to understand who initiated the dialog from SRS perspective in case SRS has more configuration/metadata information about the participant. Please let me know whether it is worth to add this information as part of participant metadata information. =20 Thanks Partha ------_=_NextPart_001_01CBAB3C.D46FCA83 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
From = the current=20 metadata parameters, it is not possible for SRS to deduce whether the=20 participant is acting as "uac" or "uas" for a given transaction in = CS but=20 SRC is aware of this information in most of the = scenarios. Participant=20 role information in CS will be lost as RS is not carry this=20 information as part of metadata. IMO, it is better to add this = information as=20 participant role with value as "uac" or "uas"  or "don't know" in = the=20 metadata.
 
This = information=20 helps to understand who initiated the dialog from SRS perspective in = case SRS=20 has more configuration/metadata information about the participant.=20 Please let=20 me know whether it is worth to add this information as part of = participant=20 metadata information.
 
Thanks
Partha
------_=_NextPart_001_01CBAB3C.D46FCA83-- From Leon.Portman@nice.com Mon Jan 3 04:02:07 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3ABC28C113 for ; Mon, 3 Jan 2011 04:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyPrIKMD6GVq for ; Mon, 3 Jan 2011 04:02:06 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id 8BEF228C103 for ; Mon, 3 Jan 2011 04:02:05 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Mon, 3 Jan 2011 14:04:11 +0200 From: Leon Portman To: "Parthasarathi R (partr)" , "Ken Rehor (krehor)" , "siprec@ietf.org" Date: Mon, 3 Jan 2011 14:04:10 +0200 Thread-Topic: [siprec] draft-ietf-siprec-req-06 posted Thread-Index: AcupemC/6QmwULhdT5CrRoSmufArYQBrQkUQAARtwRA= Message-ID: <07465C1D981ABC41A344374066AE1A2C389EB6D950@TLVMBX01.nice.com> References: <7744FE52C78D944587F03773EB45146109139DEE@xmb-sjc-22e.amer.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_07465C1D981ABC41A344374066AE1A2C389EB6D950TLVMBX01nicec_" MIME-Version: 1.0 Subject: Re: [siprec] draft-ietf-siprec-req-06 posted X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 12:02:07 -0000 --_000_07465C1D981ABC41A344374066AE1A2C389EB6D950TLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Partha, Hi I am not sure about removing. It is requirement level document and how to i= mplement it either via policy and metadata indication it is more protocol l= evel decision. >From my point of view it is also two separate flows: indicating retention p= arameters or immediate stop of the recording. For example, SRC for some reason wants to cancel recording, the best way wi= ll be to send BYE with specific error code and not metadata update event. Regards Leon From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Parthasarathi R (partr) Sent: Monday, January 03, 2011 11:24 AM To: Ken Rehor (krehor); siprec@ietf.org Subject: Re: [siprec] draft-ietf-siprec-req-06 posted Ken and all, During the last interim meeting, it was decided to put the "forced deletion= " attribute in the appdata of Metadata model instead of including in the mo= del. Cancel and discard recording from SRC is considered as policy mechanis= m passing to SRS. If so, the following requirements has to be removed from = SIPREC requirement: o REQ-015: The mechanism MUST support a means to cancel and discard the recording and associated metadata for a CS. o REQ-016: The mechanism MUST support a means to cancel and discard the recording but not the associated metadata for a CS. Please let me know your opinion on the same. Thanks Partha ________________________________ From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Ken Rehor (krehor) Sent: Saturday, January 01, 2011 11:39 AM To: siprec@ietf.org Subject: [siprec] draft-ietf-siprec-req-06 posted - ietf-siprec-req-06 posted http://www.ietf.org/internet-drafts= /draft-ietf-siprec-req-06.txt - tracker item #61 closed - Draft and change log attached Happy New Year! Ken For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --_000_07465C1D981ABC41A344374066AE1A2C389EB6D950TLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Partha, Hi=

 

I am not sure about rem= oving. It is requirement level document and how to implement it either via = policy and metadata indication it is more protocol level decision.

From my point of view it is also two separate flows: = indicating retention parameters or immediate stop of the recording.

 

For example, SR= C for some reason wants to cancel recording, the best way will be to send B= YE with specific error code and not metadata update event.

 

Regards

 

Leon<= /p>

 

= From:= siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf O= f Parthasarathi R (partr)
Sent: Monday, January 03, 2011 11:2= 4 AM
To: Ken Rehor (krehor); siprec@ietf.org
Subject: R= e: [siprec] draft-ietf-siprec-req-06 posted

 

Ken and = all,

 

<= p class=3DMsoNormal>During the last interim meeting, it was decided to pu= t the "forced deletion" attribute in the appdata of Metadata mode= l instead of including in the model. Cancel and discard recording= from SRC is considered as policy mechanism passing to SRS. If so, the= following requirements has to be removed from SIPREC requirement:<= /o:p>

 

Please let me know your= opinion on the same.

 <= /o:p>

Thanks

Partha

From: si= prec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Ken Rehor (krehor)
Sent: Saturday, January 01, 2011 11:39 AM
<= b>To: siprec@ietf.org
Subject: [siprec] draft-ietf-siprec-req= -06 posted

-          ietf-siprec-req-06 posted    http://www.ietf.org/internet= -drafts/draft-ietf-siprec-req-06.txt

-       = ;   tracker item #61 closed

-      &= nbsp;   Draft and change log attached

 

Happy New Year!

 

= Ken

 

 

For corporate legal information go to= :
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

 

= --_000_07465C1D981ABC41A344374066AE1A2C389EB6D950TLVMBX01nicec_-- From Leon.Portman@nice.com Mon Jan 3 04:03:51 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BD8728C10F for ; Mon, 3 Jan 2011 04:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtgUUWkM83Vo for ; Mon, 3 Jan 2011 04:03:50 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id B864528C103 for ; Mon, 3 Jan 2011 04:03:49 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Mon, 3 Jan 2011 14:05:56 +0200 From: Leon Portman To: "Parthasarathi R (partr)" , "siprec@ietf.org" Date: Mon, 3 Jan 2011 14:05:55 +0200 Thread-Topic: Participant role parameter in Metadata model Thread-Index: AcurPNRLSEZshgfrQy2dByCWghDbygAAbA3A Message-ID: <07465C1D981ABC41A344374066AE1A2C389EB6D952@TLVMBX01.nice.com> References: In-Reply-To: Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: multipart/alternative; boundary="_000_07465C1D981ABC41A344374066AE1A2C389EB6D952TLVMBX01nicec_" MIME-Version: 1.0 Subject: Re: [siprec] Participant role parameter in Metadata model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 12:03:51 -0000 --_000_07465C1D981ABC41A344374066AE1A2C389EB6D952TLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, it is very important Leon From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Parthasarathi R (partr) Sent: Monday, January 03, 2011 1:53 PM To: siprec@ietf.org Subject: [siprec] Participant role parameter in Metadata model Hi all, >From the current metadata parameters, it is not possible for SRS to deduce = whether the participant is acting as "uac" or "uas" for a given transaction= in CS but SRC is aware of this information in most of the scenarios. Parti= cipant role information in CS will be lost as RS is not carry this informat= ion as part of metadata. IMO, it is better to add this information as parti= cipant role with value as "uac" or "uas" or "don't know" in the metadata. This information helps to understand who initiated the dialog from SRS pers= pective in case SRS has more configuration/metadata information about the p= articipant. Please let me know whether it is worth to add this information = as part of participant metadata information. Thanks Partha --_000_07465C1D981ABC41A344374066AE1A2C389EB6D952TLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, it is = very  important

&= nbsp;

Leon

<= p class=3DMsoNormal> 

From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] <= b>On Behalf Of Parthasarathi R (partr)
Sent: Monday, January = 03, 2011 1:53 PM
To: siprec@ietf.org
Subject: [siprec] = Participant role parameter in Metadata model

 

Hi all,

 

=

From the current metadata parameters, it is not possible f= or SRS to deduce whether the participant is acting as "uac" or &q= uot;uas" for a given transaction in CS but SRC is aware of this i= nformation in most of the scenarios. Participant role information= in CS will be lost as RS is not carry this information as part of met= adata. IMO, it is better to add this information as participant role with v= alue as "uac" or "uas"  or "don't know" = in the metadata.

&nbs= p;

This information helps to understan= d who initiated the dialog from SRS perspective in case SRS has more config= uration/metadata information about the participant. Please let me know whet= her it is worth to add this information as part of participant metadata inf= ormation.

 <= /o:p>

Thanks

Partha

= --_000_07465C1D981ABC41A344374066AE1A2C389EB6D952TLVMBX01nicec_-- From pkyzivat@cisco.com Mon Jan 3 07:54:30 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31D573A6A08 for ; Mon, 3 Jan 2011 07:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.46 X-Spam-Level: X-Spam-Status: No, score=-110.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlCrkRZ7VsvK for ; Mon, 3 Jan 2011 07:54:29 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E52A13A69FF for ; Mon, 3 Jan 2011 07:54:28 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcGAJuAIU1AZnwM/2dsb2JhbACWF44dc6J4mF2FSgSEZYYfgx0 X-IronPort-AV: E=Sophos;i="4.60,267,1291593600"; d="scan'208";a="199224313" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 03 Jan 2011 15:56:35 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p03FuZs4000602 for ; Mon, 3 Jan 2011 15:56:35 GMT Message-ID: <4D21F1B3.3060301@cisco.com> Date: Mon, 03 Jan 2011 10:56:35 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: siprec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Participant role parameter in Metadata model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 15:54:30 -0000 On 1/3/2011 6:53 AM, Parthasarathi R (partr) wrote: > Hi all, > From the current metadata parameters, it is not possible for SRS to > deduce whether the participant is acting as "uac" or "uas" for a given > transaction in CS but SRC is aware of this information in most of the > scenarios. Participant role information in CS will be lost as RS is not > carry this information as part of metadata. IMO, it is better to add > this information as participant role with value as "uac" or "uas" or > "don't know" in the metadata. > This information helps to understand who initiated the dialog from SRS > perspective in case SRS has more configuration/metadata information > about the participant. Please let me know whether it is worth to add > this information as part of participant metadata information. > Thanks > Partha Its at least going to take some thought to get this right. The metadata we have defined isn't really structured transactionally the same way sip is. Its more "declarative" than operational. So for instance, there might be a metadata change that adds an additional media stream. There may have been multiple sip transactions take place to negotiate that new media stream. One specific participant may have sent the first transaction that initiated an o/a negotiation that resulted in the new media stream. But its possible the the first offer of that stream came from a different participant. Now, perhaps there is some interest in recording all, or a summary, of all the sip traffic on the CS as part of the metadata. But that is likely to be overkill. If not, then I think roles such as UAC and UAS need to be translated into something that makes sense in the metadata. I'm not entirely sure what that would be - it varies for different pieces of the metadata. Thanks, Paul > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@cisco.com Mon Jan 3 07:58:49 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BF633A69FF for ; Mon, 3 Jan 2011 07:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.463 X-Spam-Level: X-Spam-Status: No, score=-110.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stpCvKiiWkSW for ; Mon, 3 Jan 2011 07:58:48 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E97863A6980 for ; Mon, 3 Jan 2011 07:58:47 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcGAMaBIU1AZnwM/2dsb2JhbACWF44dc6JsmF2FSgSEZYYfgx0 X-IronPort-AV: E=Sophos;i="4.60,267,1291593600"; d="scan'208";a="199225902" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 03 Jan 2011 16:00:55 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p03G0svr002893 for ; Mon, 3 Jan 2011 16:00:54 GMT Message-ID: <4D21F2B6.8030304@cisco.com> Date: Mon, 03 Jan 2011 11:00:54 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: siprec@ietf.org References: <7744FE52C78D944587F03773EB45146109139DEE@xmb-sjc-22e.amer.cisco.com> <07465C1D981ABC41A344374066AE1A2C389EB6D950@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C389EB6D950@TLVMBX01.nice.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] draft-ietf-siprec-req-06 posted X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 15:58:49 -0000 ISTM there are two parts to this: - a mechanism for the SRC to indicate its desire to stop/cancel the recording and discard the media and/or metadata. - a policy at the SRS whether to honor such a request. The requirements aren't phrased that way. If they were, would it satisfy everybody? Thanks, Paul On 1/3/2011 7:04 AM, Leon Portman wrote: > Partha, Hi > > I am not sure about removing. It is requirement level document and how > to implement it either via policy and metadata indication it is more > protocol level decision. > > From my point of view it is also two separate flows: indicating > retention parameters or immediate stop of the recording. > > For example, SRC for some reason wants to cancel recording, the best way > will be to send BYE with specific error code and not metadata update event. > > Regards > > Leon > > *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On > Behalf Of *Parthasarathi R (partr) > *Sent:* Monday, January 03, 2011 11:24 AM > *To:* Ken Rehor (krehor); siprec@ietf.org > *Subject:* Re: [siprec] draft-ietf-siprec-req-06 posted > > Ken and all, > > During the last interim meeting, it was decided to put the "forced > deletion" attribute in the appdata of Metadata model instead of > including in the model. Cancel and discard recording from SRC is > considered as policy mechanism passing to SRS. If so, the following > requirements has to be removed from SIPREC requirement: > > o REQ-015: The mechanism MUST support a means to cancel and discard > the recording and associated metadata for a CS. > > o REQ-016: The mechanism MUST support a means to cancel and discard > the recording but not the associated metadata for a CS. > > Please let me know your opinion on the same. > > Thanks > > Partha > > ------------------------------------------------------------------------ > > *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On > Behalf Of *Ken Rehor (krehor) > *Sent:* Saturday, January 01, 2011 11:39 AM > *To:* siprec@ietf.org > *Subject:* [siprec] draft-ietf-siprec-req-06 posted > > -ietf-siprec-req-06 posted > http://www.ietf.org/internet-drafts/draft-ietf-siprec-req-06.txt > > -tracker item #61 closed > > -Draft and change log attached > > Happy New Year! > > Ken > > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Mon Jan 3 09:21:28 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C66AB3A68C9 for ; Mon, 3 Jan 2011 09:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIISD-aWeTSi for ; Mon, 3 Jan 2011 09:21:25 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 349033A67C0 for ; Mon, 3 Jan 2011 09:21:21 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2877142 for siprec@ietf.org; Mon, 3 Jan 2011 18:23:28 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 786901EB82B6 for ; Mon, 3 Jan 2011 18:23:28 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 3 Jan 2011 18:23:28 +0100 From: "Elwell, John" To: "siprec@ietf.org" Date: Mon, 3 Jan 2011 18:23:27 +0100 Thread-Topic: WGLC on draft-ietf-siprec-req-06 Thread-Index: Acurau650C2nwOvwRD22OPWO+pjQmw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] WGLC on draft-ietf-siprec-req-06 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 17:21:29 -0000 I hereby initiate a 2-week Working Group Last Call on this document. Please= submit your comments by 2011-01-17. Even if you don't have any comments, p= lease indicate that you have reviewed the document. John From john.elwell@siemens-enterprise.com Mon Jan 3 09:21:42 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3A6B3A6979 for ; Mon, 3 Jan 2011 09:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svf0+EssNmmc for ; Mon, 3 Jan 2011 09:21:41 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id C11E53A6935 for ; Mon, 3 Jan 2011 09:21:40 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2870039; Mon, 3 Jan 2011 18:23:46 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 780551EB82B8; Mon, 3 Jan 2011 18:23:46 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 3 Jan 2011 18:23:46 +0100 From: "Elwell, John" To: "Parthasarathi R (partr)" , "Ken Rehor (krehor)" , "siprec@ietf.org" Date: Mon, 3 Jan 2011 18:23:44 +0100 Thread-Topic: [siprec] draft-ietf-siprec-req-06 posted Thread-Index: AcupemC/6QmwULhdT5CrRoSmufArYQBrQkUQABDTYcA= Message-ID: References: <7744FE52C78D944587F03773EB45146109139DEE@xmb-sjc-22e.amer.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] draft-ietf-siprec-req-06 posted X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 17:21:42 -0000 Notwithstanding this comment from Partha, I have started WGLC on the docume= nt. Please treat this as a WGLC comment. John=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) > Sent: 03 January 2011 09:24 > To: Ken Rehor (krehor); siprec@ietf.org > Subject: Re: [siprec] draft-ietf-siprec-req-06 posted >=20 > Ken and all, > =20 > During the last interim meeting, it was decided to put the=20 > "forced deletion" attribute in the appdata of Metadata model=20 > instead of including in the model. Cancel and discard=20 > recording from SRC is considered as policy mechanism passing=20 > to SRS. If so, the following requirements has to be removed=20 > from SIPREC requirement: > =20 > o REQ-015: The mechanism MUST support a means to cancel and discard > the recording and associated metadata for a CS. >=20 > o REQ-016: The mechanism MUST support a means to cancel and discard > the recording but not the associated metadata for a CS. >=20 > Please let me know your opinion on the same. > =20 > Thanks > Partha > ________________________________ >=20 > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Ken Rehor (krehor) > Sent: Saturday, January 01, 2011 11:39 AM > To: siprec@ietf.org > Subject: [siprec] draft-ietf-siprec-req-06 posted >=20 >=20 >=20 > - ietf-siprec-req-06 posted =20 > http://www.ietf.org/internet-drafts/draft-ietf-siprec-req-06.txt >=20 > - tracker item #61 closed >=20 > - Draft and change log attached >=20 > =20 >=20 > Happy New Year! >=20 > =20 >=20 > Ken >=20 > =20 >=20 > =20 >=20 > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 > =20 >=20 > = From partr@cisco.com Mon Jan 3 17:18:42 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E0043A6868 for ; Mon, 3 Jan 2011 17:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.372 X-Spam-Level: X-Spam-Status: No, score=-9.372 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38EWcQZG+sC6 for ; Mon, 3 Jan 2011 17:18:40 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id B116E3A6867 for ; Mon, 3 Jan 2011 17:18:40 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFAFMEIk1AaMHG/2dsb2JhbACCKaEuXnOiNJkbhUoEhGOJRA X-IronPort-AV: E=Sophos;i="4.60,269,1291593600"; d="scan'208,217";a="240047488" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 04 Jan 2011 01:20:47 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p041KjFd020177; Tue, 4 Jan 2011 01:20:45 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Jan 2011 06:50:44 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBABAD.9BEC82B4" Date: Tue, 4 Jan 2011 06:50:44 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] draft-ietf-siprec-req-06 posted Thread-Index: AcupemC/6QmwULhdT5CrRoSmufArYQBrQkUQAARtwRAAHIFEiA== References: <7744FE52C78D944587F03773EB45146109139DEE@xmb-sjc-22e.amer.cisco.com> <07465C1D981ABC41A344374066AE1A2C389EB6D950@TLVMBX01.nice.com> From: "Parthasarathi R (partr)" To: "Leon Portman" , "Ken Rehor (krehor)" , X-OriginalArrivalTime: 04 Jan 2011 01:20:44.0891 (UTC) FILETIME=[9C39B2B0:01CBABAD] Subject: Re: [siprec] draft-ietf-siprec-req-06 posted X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 01:18:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBABAD.9BEC82B4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Leon, =20 Please read inline. =20 Thanks Partha ________________________________ From: Leon Portman [mailto:Leon.Portman@nice.com] Sent: Mon 1/3/2011 5:34 PM To: Parthasarathi R (partr); Ken Rehor (krehor); siprec@ietf.org Subject: RE: [siprec] draft-ietf-siprec-req-06 posted Partha, Hi =20 I am not sure about removing. It is requirement level document and how = to implement it either via policy=20 In case of policy, there is no need of configuration and metadata indication it is more protocol level decision. As per the last meeting, the information is not passed in = metadata model. If required, we need to revisit the metadata model = parameters >From my point of view it is also two separate flows: indicating = retention parameters or immediate stop of the recording. The requirement wordings does not look like stop of the = recording. The intention is to cancel and discard the existing recording = of specific RS For example, SRC for some reason wants to cancel recording, the best way = will be to send BYE with specific error code and not metadata update = event. I agree that different way to achieve it in SIPREC solution. = Metadata model composes of all recording related signaling information = passed between between SRS and SRC. As part of SIPREC solution, We may = decide to use error code in BYE to cancel and discard recording but we = have to represent it in the metadata model. Please let me know your = opinion here. =20 Regards =20 Leon =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf = Of Parthasarathi R (partr) Sent: Monday, January 03, 2011 11:24 AM To: Ken Rehor (krehor); siprec@ietf.org Subject: Re: [siprec] draft-ietf-siprec-req-06 posted =20 Ken and all, =20 During the last interim meeting, it was decided to put the "forced = deletion" attribute in the appdata of Metadata model instead of = including in the model. Cancel and discard recording from SRC is = considered as policy mechanism passing to SRS. If so, the following = requirements has to be removed from SIPREC requirement: =20 o REQ-015: The mechanism MUST support a means to cancel and discard the recording and associated metadata for a CS. o REQ-016: The mechanism MUST support a means to cancel and discard the recording but not the associated metadata for a CS. Please let me know your opinion on the same. =20 Thanks Partha ________________________________ From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf = Of Ken Rehor (krehor) Sent: Saturday, January 01, 2011 11:39 AM To: siprec@ietf.org Subject: [siprec] draft-ietf-siprec-req-06 posted - ietf-siprec-req-06 posted = http://www.ietf.org/internet-drafts/draft-ietf-siprec-req-06.txt - tracker item #61 closed - Draft and change log attached =20 Happy New Year! =20 Ken =20 =20 For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 ------_=_NextPart_001_01CBABAD.9BEC82B4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A=
=0A=
Leon,
=0A=
 
=0A=
Please read = inline.
=0A=
 
=0A=
Thanks
=0A=
Partha
=0A=

=0A=
=0A= From: Leon Portman = [mailto:Leon.Portman@nice.com]
Sent: Mon 1/3/2011 5:34 = PM
To: Parthasarathi R (partr); Ken Rehor (krehor); = siprec@ietf.org
Subject: RE: [siprec] draft-ietf-siprec-req-06 = posted

=0A=
=0A=
=0A=

Partha, Hi

=0A=

 

=0A=

I am not sure about removing. It is requirement level = document and how to implement it either via policy

=0A=

<Partha> In case of policy, there is no need of = configuration </Partha>

=0A=

and metadata indication it is more protocol level = decision.

=0A=

<Partha> As per the last meeting, the information = is not passed in metadata model. If required, we need to revisit the = metadata model parameters </Partha>

=0A=

From my point of view it is also two separate flows: = indicating retention parameters or immediate stop of the = recording.

=0A=

<Partha> The requirement wordings does not look = like stop of the recording. The intention is to cancel and discard the = existing recording of specific RS </Partha>

=0A=

For example, SRC for some reason wants to cancel = recording, the best way will be to send BYE with specific error code and = not metadata update event.

=0A=

<Partha> I agree that different way to achieve it = in SIPREC solution. Metadata model composes of all recording = related signaling information passed between between SRS and = SRC. As part of SIPREC solution, We may decide to use error code in = BYE to cancel and discard recording but we have to represent = it in the metadata model. Please let me know your opinion = here. </Partha>

=0A=

 

=0A=

Regards

=0A=

 

=0A=

Leon

=0A=

 

=0A=
=0A=
=0A=

From: = siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Parthasarathi R (partr)
Sent: Monday, January 03, 2011 = 11:24 AM
To: Ken Rehor (krehor); = siprec@ietf.org
Subject: Re: [siprec] draft-ietf-siprec-req-06 = posted

=0A=

 

=0A=

Ken and all,

=0A=

 

=0A=

During the last interim meeting, it was = decided to put the "forced deletion" attribute in the appdata of = Metadata model instead of including in the model. Cancel = and discard recording from SRC is considered as policy = mechanism passing to SRS. If so, the following requirements has to = be removed from SIPREC requirement:

=0A=

 

=0A=

   o REQ-015: The mechanism = MUST support a means to cancel and discard
   the recording = and associated metadata for a CS.

   o REQ-016: The = mechanism MUST support a means to cancel and discard
   the = recording but not the associated metadata for a CS.

=0A=

Please let me know your opinion on the = same.

=0A=

 

=0A=

Thanks

=0A=

Partha

=0A=
=0A=
=0A=
=0A=

From: siprec-bounces@ietf.org = [mailto:siprec-bounces@ietf.org] On Behalf Of Ken Rehor = (krehor)
Sent: Saturday, January 01, 2011 11:39 = AM
To: siprec@ietf.org
Subject: [siprec] = draft-ietf-siprec-req-06 posted

=0A=

-          = ietf-siprec-req-06 posted    http://www.ietf.org/internet-drafts/draft-ietf-siprec-req-06.txt

=0A=

-          = tracker item #61 closed

=0A=

-          Draft = and change log attached

=0A=

 

=0A=

Happy New Year!

=0A=

 

=0A=

Ken

=0A=

 

=0A=

 

=0A=

For corporate legal information go = to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

=0A=

 

------_=_NextPart_001_01CBABAD.9BEC82B4-- From deepanshu@huawei.com Mon Jan 3 18:19:24 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFD443A693C for ; Mon, 3 Jan 2011 18:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=1.671, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGT3wNYLhXgh for ; Mon, 3 Jan 2011 18:19:18 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 459B93A693B for ; Mon, 3 Jan 2011 18:19:18 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEH00GTQ7TAFM@szxga04-in.huawei.com> for siprec@ietf.org; Tue, 04 Jan 2011 10:19:58 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEH006167TAKV@szxga04-in.huawei.com> for siprec@ietf.org; Tue, 04 Jan 2011 10:19:58 +0800 (CST) Received: from d57531b ([10.138.73.34]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEH008YR7T6K6@szxml06-in.huawei.com> for siprec@ietf.org; Tue, 04 Jan 2011 10:19:58 +0800 (CST) Date: Tue, 04 Jan 2011 10:19:54 +0800 From: Deepanshu Gautam In-reply-to: To: "'Parthasarathi R (partr)'" , 'Leon Portman' , "'Ken Rehor (krehor)'" , siprec@ietf.org Message-id: <008b01cbabb5$dfde01d0$9f9a0570$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_EJb3/crSZ50SJcehL1DmtA)" Content-language: en-us Thread-index: AcupemC/6QmwULhdT5CrRoSmufArYQBrQkUQAARtwRAAHIFEiAACXfOQ References: <7744FE52C78D944587F03773EB45146109139DEE@xmb-sjc-22e.amer.cisco.com> <07465C1D981ABC41A344374066AE1A2C389EB6D950@TLVMBX01.nice.com> Subject: Re: [siprec] draft-ietf-siprec-req-06 posted X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 02:19:24 -0000 This is a multi-part message in MIME format. --Boundary_(ID_EJb3/crSZ50SJcehL1DmtA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I think the original intention for these requirements was indeed the stop of recording and/or discard any metadata already submitted. The word 'cancel' *is* implying a stop-of-recording. You don't cancel existing recording, you delete existing/discard recording. I think the wording is fine. We can add something related with "- a policy at the SRS whether to honor such a request." If we really need that at requirement level Regards Deepanshu Gautam T: +86 25 5260008 M: +86 135 85147627 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) Sent: Tuesday, January 04, 2011 9:21 AM To: Leon Portman; Ken Rehor (krehor); siprec@ietf.org Subject: Re: [siprec] draft-ietf-siprec-req-06 posted Leon, Please read inline. Thanks Partha _____ From: Leon Portman [mailto:Leon.Portman@nice.com] Sent: Mon 1/3/2011 5:34 PM To: Parthasarathi R (partr); Ken Rehor (krehor); siprec@ietf.org Subject: RE: [siprec] draft-ietf-siprec-req-06 posted Partha, Hi I am not sure about removing. It is requirement level document and how to implement it either via policy In case of policy, there is no need of configuration and metadata indication it is more protocol level decision. As per the last meeting, the information is not passed in metadata model. If required, we need to revisit the metadata model parameters >From my point of view it is also two separate flows: indicating retention parameters or immediate stop of the recording. The requirement wordings does not look like stop of the recording. The intention is to cancel and discard the existing recording of specific RS For example, SRC for some reason wants to cancel recording, the best way will be to send BYE with specific error code and not metadata update event. I agree that different way to achieve it in SIPREC solution. Metadata model composes of all recording related signaling information passed between between SRS and SRC. As part of SIPREC solution, We may decide to use error code in BYE to cancel and discard recording but we have to represent it in the metadata model. Please let me know your opinion here. Regards Leon From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) Sent: Monday, January 03, 2011 11:24 AM To: Ken Rehor (krehor); siprec@ietf.org Subject: Re: [siprec] draft-ietf-siprec-req-06 posted Ken and all, During the last interim meeting, it was decided to put the "forced deletion" attribute in the appdata of Metadata model instead of including in the model. Cancel and discard recording from SRC is considered as policy mechanism passing to SRS. If so, the following requirements has to be removed from SIPREC requirement: o REQ-015: The mechanism MUST support a means to cancel and discard the recording and associated metadata for a CS. o REQ-016: The mechanism MUST support a means to cancel and discard the recording but not the associated metadata for a CS. Please let me know your opinion on the same. Thanks Partha _____ From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ken Rehor (krehor) Sent: Saturday, January 01, 2011 11:39 AM To: siprec@ietf.org Subject: [siprec] draft-ietf-siprec-req-06 posted - ietf-siprec-req-06 posted http://www.ietf.org/internet-drafts/draft-ietf-siprec-req-06.txt - tracker item #61 closed - Draft and change log attached Happy New Year! Ken For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --Boundary_(ID_EJb3/crSZ50SJcehL1DmtA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

I think the original intention for these requirements was indeed the stop of recording and/or discard any metadata already submitted. The word ‘cancel’ *is* implying a stop-of-recording. You don’t cancel existing recording, you delete existing/discard recording. I think the wording is fine.

 

We can add something related with “- a policy at the SRS whether to honor such a request.” If we really need that at requirement level

  < Regards

 

Deepanshu Gautam

T: +86 25 5260008 M: +86 135 85147627

 

From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr)
Sent: Tues day, Jan To: Leon Portman; Ken Rehor (krehor); siprec@ietf.org
Subject: Re: [siprec] draft-ietf-siprec-req-06 posted

 

Leon,

 

Please read inline.

 

Th anks

Partha

 

From: Leon Portman [mailto:Leon.Portman@nice.com]
Sent: Mon 1/3/2011 5:34 PM
To: Parthasarathi R (partr); Ken Rehor (krehor); siprec@ietf.org
Subject: RE: [siprec] draft-ietf-siprec-req-06 posted

Partha, Hi

 

I am not sure about removing. It is requirement level document and how to implement it either via policy

<Partha> In case of policy, there is no need of configuration </Partha>

and metadata indication it is more protocol level decision.

<Partha> As per the last meeting, the information is not passed in metadata model. If required, we need to revisit th e metada Partha>

From my point of view it is also two separate flows: indicating retention parameters or immediate stop of the recording.

<Partha> The requirement wordings does not look like stop of the recording. The intention is to cancel and discard the existing recording of specific RS </Partha>

For example, SRC for some reason wants to cancel recording, the best way will be to send BYE with specific error code and not metadata update event.

<Partha> I agree that different way to achieve it in SIPREC solution. Metadata model composes of all recording related& nbsp;sig between between SRS and SRC. As part of SIPREC solution, We may decide to use error code in BYE to cancel and discard recording but we have to represent it in the metadata model. Please let me know your opinion here. </Partha>

 

Regards

 

Leon

 

From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr)
Sent: Monday, January To: Ken Rehor (krehor); siprec@ietf.org
Subject: Re: [siprec] draft-ietf-siprec-req-06 posted

 

Ken and all,

 

During the last interim meeting, it was decided to put the "forced deletion" attribute in the appdata of Metadata model instead of including in the model. Cancel and discard recording from SRC is considered as policy mechanism passing to SRS. If so, the following requirements has to be removed from SIPREC requirement:

 

   o REQ-015: The mechanism MUST support a means to bsp;  the recording and associated metadata for a CS.

   o REQ-016: The mechanism MUST support a means to cancel and discard
   the recording but not the associated metadata for a CS.

Please let me know your opinion on the same.

 

Thanks

Partha

From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ken Rehor (krehor)
Sent: Saturday, January 01, 2011 11:39 AM
To: siprec@ietf.org
Subject: [siprec] draft-ietf-siprec-req-06 posted

-          ietf-siprec-req-06 posted    http://www.ietf.org/internet-drafts/draft-ietf-siprec-req-06.txt

-          tracker item #61 closed

-          Draft and change log attached

 

Happy New Year!

 

Ken

 

 

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

 

--Boundary_(ID_EJb3/crSZ50SJcehL1DmtA)-- From partr@cisco.com Mon Jan 3 22:55:00 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C5B63A6B3F for ; Mon, 3 Jan 2011 22:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.066 X-Spam-Level: X-Spam-Status: No, score=-10.066 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XNALpXroHIF for ; Mon, 3 Jan 2011 22:54:52 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 452E23A6B3C for ; Mon, 3 Jan 2011 22:54:51 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcFAAJUIk1AaMHG/2dsb2JhbACCKaINc6IemSWFSgSEY4lE X-IronPort-AV: E=Sophos;i="4.60,271,1291593600"; d="scan'208,217";a="240118648" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 04 Jan 2011 06:56:57 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p046urSV018157; Tue, 4 Jan 2011 06:56:55 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Jan 2011 12:26:52 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBABDC.90FE2C7C" Date: Tue, 4 Jan 2011 12:26:52 +0530 Message-ID: In-Reply-To: <008b01cbabb5$dfde01d0$9f9a0570$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Metadata with "forced deletion" attribute [was RE: [siprec] draft-ietf-siprec-req-06 posted] Thread-Index: AcupemC/6QmwULhdT5CrRoSmufArYQBrQkUQAARtwRAAHIFEiAACXfOQAAiPuQA= References: <7744FE52C78D944587F03773EB45146109139DEE@xmb-sjc-22e.amer.cisco.com> <07465C1D981ABC41A344374066AE1A2C389EB6D950@TLVMBX01.nice.com> <008b01cbabb5$dfde01d0$9f9a0570$@com> From: "Parthasarathi R (partr)" To: "Deepanshu Gautam" , "Leon Portman" , "Ken Rehor (krehor)" , X-OriginalArrivalTime: 04 Jan 2011 06:56:52.0806 (UTC) FILETIME=[913D4E60:01CBABDC] Subject: [siprec] Metadata with "forced deletion" attribute [was RE: draft-ietf-siprec-req-06 posted] X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 06:55:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBABDC.90FE2C7C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Incase everyone feels that REQ-15 and REQ-16 requirements are required, I'm fine. I'm worried from the metadata model as we are planning to remove "forced deletion" attribute in CS. ISTM, metadata model is inconsistent w.r.t requirement.=20 =20 IMO, we need to add the "forced deletion" attribute in CS of metadata model to meet REQ-15 and REQ-16 with attribute values as =20 1) Complete 2) Media deletion only =20 The solution document will provide the realization (like BYE with extra SIP header) for this attribute. Please let me know your opinion on the same. =20 Thanks Partha ________________________________ From: Deepanshu Gautam [mailto:deepanshu@huawei.com]=20 Sent: Tuesday, January 04, 2011 7:50 AM To: Parthasarathi R (partr); 'Leon Portman'; Ken Rehor (krehor); siprec@ietf.org Subject: RE: [siprec] draft-ietf-siprec-req-06 posted I think the original intention for these requirements was indeed the stop of recording and/or discard any metadata already submitted. The word 'cancel' *is* implying a stop-of-recording. You don't cancel existing recording, you delete existing/discard recording. I think the wording is fine. =20 We can add something related with "- a policy at the SRS whether to honor such a request." If we really need that at requirement level < Regards =20 Deepanshu Gautam T: +86 25 5260008 M: +86 135 85147627 =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) Sent: Tuesday, Jan To: Leon Portman; Ken Rehor (krehor); siprec@ietf.org Subject: Re: [siprec] draft-ietf-siprec-req-06 posted =20 Leon, =20 Please read inline. =20 Thanks Partha =20 ________________________________ From: Leon Portman [mailto:Leon.Portman@nice.com] Sent: Mon 1/3/2011 5:34 PM To: Parthasarathi R (partr); Ken Rehor (krehor); siprec@ietf.org Subject: RE: [siprec] draft-ietf-siprec-req-06 posted Partha, Hi =20 I am not sure about removing. It is requirement level document and how to implement it either via policy=20 In case of policy, there is no need of configuration and metadata indication it is more protocol level decision. As per the last meeting, the information is not passed in metadata model. If required, we need to revisit the metada Partha> >From my point of view it is also two separate flows: indicating retention parameters or immediate stop of the recording. The requirement wordings does not look like stop of the recording. The intention is to cancel and discard the existing recording of specific RS For example, SRC for some reason wants to cancel recording, the best way will be to send BYE with specific error code and not metadata update event. I agree that different way to achieve it in SIPREC solution. Metadata model composes of all recording related sig between between SRS and SRC. As part of SIPREC solution, We may decide to use error code in BYE to cancel and discard recording but we have to represent it in the metadata model. Please let me know your opinion here. =20 Regards =20 Leon =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) Sent: Monday, January To: Ken Rehor (krehor); siprec@ietf.org Subject: Re: [siprec] draft-ietf-siprec-req-06 posted =20 Ken and all, =20 During the last interim meeting, it was decided to put the "forced deletion" attribute in the appdata of Metadata model instead of including in the model. Cancel and discard recording from SRC is considered as policy mechanism passing to SRS. If so, the following requirements has to be removed from SIPREC requirement: =20 o REQ-015: The mechanism MUST support a means to bsp; the recording and associated metadata for a CS. o REQ-016: The mechanism MUST support a means to cancel and discard the recording but not the associated metadata for a CS. Please let me know your opinion on the same. =20 Thanks Partha ________________________________ From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ken Rehor (krehor) Sent: Saturday, January 01, 2011 11:39 AM To: siprec@ietf.org Subject: [siprec] draft-ietf-siprec-req-06 posted - ietf-siprec-req-06 posted http://www.ietf.org/internet-drafts/draft-ietf-siprec-req-06.txt - tracker item #61 closed - Draft and change log attached =20 Happy New Year! =20 Ken =20 =20 For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 ------_=_NextPart_001_01CBABDC.90FE2C7C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Incase everyone feels that REQ-15 and=20 REQ-16 requirements are required, I'm fine. I'm worried from the = metadata=20 model as we are planning to remove "forced deletion" attribute in CS. = ISTM,=20 metadata model is inconsistent w.r.t requirement.
 
IMO, we need to add the "forced = deletion" attribute=20 in CS of metadata model to meet REQ-15 and REQ-16 with = attribute=20 values as
 
1) Complete
2) Media deletion only
 
The solution document will provide the realization = (like BYE=20 with extra SIP header) for this attribute. Please let me know your = opinion=20 on the same.
 
Thanks
Partha
From: Deepanshu Gautam=20 [mailto:deepanshu@huawei.com]
Sent: Tuesday, January 04, 2011 = 7:50=20 AM
To: Parthasarathi R (partr); 'Leon Portman'; Ken Rehor = (krehor);=20 siprec@ietf.org
Subject: RE: [siprec] draft-ietf-siprec-req-06 = posted

I think the original = intention=20 for these requirements was indeed the stop of recording and/or discard = any=20 metadata already submitted. The word ‘cancel’ *is* = implying a=20 stop-of-recording. You don’t cancel existing recording, you delete = existing/discard recording. I think the wording is = fine.

 

We can add = something=20 related with “- a policy at the SRS whether to honor such a = request.” If = we really need=20 that at requirement level

 <=20 Regards

 

Deepanshu=20 Gautam

T:=20 +86 25 5260008 M: +86 135 85147627

 

From:=20 siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Parthasarathi R (partr)
Sent: Tuesday, Jan To: Leon = Portman; Ken Rehor (krehor); siprec@ietf.org
Subject: Re: = [siprec]=20 draft-ietf-siprec-req-06 posted

 

Leon,

 

Please read = inline.

 

Thanks

Partha

 

From: Leon = Portman=20 [mailto:Leon.Portman@nice.com]
Sent: Mon 1/3/2011 5:34=20 PM
To: Parthasarathi R (partr); Ken Rehor (krehor);=20 siprec@ietf.org
Subject: RE: [siprec] draft-ietf-siprec-req-06 = posted

Partha,=20 Hi

 

I am not = sure about=20 removing. It is requirement level document and how to implement it = either via=20 policy

<Partha> In case=20 of policy, there is no need of configuration=20 </Partha>

and metadata = indication it is more protocol level decision.

<Partha> As per=20 the last meeting, the information is not passed in metadata model. If = required,=20 we need to revisit the metada Partha>

From my = point of view=20 it is also two separate flows: indicating retention parameters or = immediate stop=20 of the recording.

<Partha> The=20 requirement wordings does not look like stop of the recording. The = intention is=20 to cancel and discard the existing recording of specific RS=20 </Partha>

For example, = SRC for=20 some reason wants to cancel recording, the best way will be to send BYE = with=20 specific error code and not metadata update event.

<Partha> I agree=20 that different way to achieve it in SIPREC solution. Metadata model = composes of=20 all recording related sig between between SRS and SRC. As = part of=20 SIPREC solution, We may decide to use error code in BYE to cancel = and=20 discard recording but we have to represent it in the metadata = model. Please=20 let me know your opinion = here. </Partha>

 

Regards

 

Leon

 

From:=20 siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Parthasarathi R (partr)
Sent: Monday, January To: Ken = Rehor=20 (krehor); siprec@ietf.org
Subject: Re: [siprec]=20 draft-ietf-siprec-req-06 posted

 

Ken and=20 all,

 

During=20 the last interim meeting, it was decided to put the "forced deletion" = attribute=20 in the appdata of Metadata model instead of including in the model. = Cancel=20 and discard recording from SRC is considered as policy = mechanism=20 passing to SRS. If so, the following requirements has to be removed = from=20 SIPREC requirement:

 

   o=20 REQ-015: The mechanism MUST support a means to bsp;  the recording = and=20 associated metadata for a CS.

   o REQ-016: The = mechanism MUST=20 support a means to cancel and discard
   the recording but = not the=20 associated metadata for a CS.

Please=20 let me know your opinion on the same.

 

Thanks

Partha

From: siprec-bounces@ietf.org=20 [mailto:siprec-bounces@ietf.org] On Behalf Of Ken Rehor=20 (krehor)
Sent: Saturday, January 01, 2011 11:39 = AM
To:=20 siprec@ietf.org
Subject: [siprec] draft-ietf-siprec-req-06=20 posted

-         =20 ietf-siprec-req-06 posted    http://www.ietf.org/internet-drafts/draft-ietf-siprec-req-06.txt

-         =20 tracker item #61 closed

-         =20 Draft and change log attached

 

Happy New Year!

 

Ken

 

 

For = corporate legal=20 information go=20 to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 

------_=_NextPart_001_01CBABDC.90FE2C7C-- From Leon.Portman@nice.com Mon Jan 3 23:35:17 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2DE63A6B4C for ; Mon, 3 Jan 2011 23:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tq8b0Wljtow for ; Mon, 3 Jan 2011 23:35:08 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id 374133A69F4 for ; Mon, 3 Jan 2011 23:35:07 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Tue, 4 Jan 2011 09:37:13 +0200 From: Leon Portman To: "Parthasarathi R (partr)" , Deepanshu Gautam , "Ken Rehor (krehor)" , "siprec@ietf.org" Date: Tue, 4 Jan 2011 09:37:11 +0200 Thread-Topic: Metadata with "forced deletion" attribute [was RE: [siprec] draft-ietf-siprec-req-06 posted] Thread-Index: AcupemC/6QmwULhdT5CrRoSmufArYQBrQkUQAARtwRAAHIFEiAACXfOQAAiPuQAAAtH/gA== Message-ID: <07465C1D981ABC41A344374066AE1A2C389EB6DBA2@TLVMBX01.nice.com> References: <7744FE52C78D944587F03773EB45146109139DEE@xmb-sjc-22e.amer.cisco.com> <07465C1D981ABC41A344374066AE1A2C389EB6D950@TLVMBX01.nice.com> <008b01cbabb5$dfde01d0$9f9a0570$@com> In-Reply-To: Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: multipart/alternative; boundary="_000_07465C1D981ABC41A344374066AE1A2C389EB6DBA2TLVMBX01nicec_" MIME-Version: 1.0 Subject: Re: [siprec] Metadata with "forced deletion" attribute [was RE: draft-ietf-siprec-req-06 posted] X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 07:35:17 -0000 --_000_07465C1D981ABC41A344374066AE1A2C389EB6DBA2TLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with the below Regards Leon From: Parthasarathi R (partr) [mailto:partr@cisco.com] Sent: Tuesday, January 04, 2011 8:57 AM To: Deepanshu Gautam; Leon Portman; Ken Rehor (krehor); siprec@ietf.org Cc: Paul Kyzivat (pkyzivat) Subject: Metadata with "forced deletion" attribute [was RE: [siprec] draft-= ietf-siprec-req-06 posted] Incase everyone feels that REQ-15 and REQ-16 requirements are required, I'm= fine. I'm worried from the metadata model as we are planning to remove "fo= rced deletion" attribute in CS. ISTM, metadata model is inconsistent w.r.t = requirement. IMO, we need to add the "forced deletion" attribute in CS of metadata model= to meet REQ-15 and REQ-16 with attribute values as 1) Complete 2) Media deletion only The solution document will provide the realization (like BYE with extra SIP= header) for this attribute. Please let me know your opinion on the same. Thanks Partha ________________________________ From: Deepanshu Gautam [mailto:deepanshu@huawei.com] Sent: Tuesday, January 04, 2011 7:50 AM To: Parthasarathi R (partr); 'Leon Portman'; Ken Rehor (krehor); siprec@iet= f.org Subject: RE: [siprec] draft-ietf-siprec-req-06 posted I think the original intention for these requirements was indeed the stop o= f recording and/or discard any metadata already submitted. The word 'cancel= ' *is* implying a stop-of-recording. You don't cancel existing recording, y= ou delete existing/discard recording. I think the wording is fine. We can add something related with "- a policy at the SRS whether to honor s= uch a request." If we really need that at requirement level < Regards Deepanshu Gautam T: +86 25 5260008 M: +86 135 85147627 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Parthasarathi R (partr) Sent: Tuesday, Jan To: Leon Portman; Ken Rehor (krehor); siprec@ietf.org Subject: Re: [siprec] draft-ietf-siprec-req-06 posted Leon, Please read inline. Thanks Partha ________________________________ From: Leon Portman [mailto:Leon.Portman@nice.com] Sent: Mon 1/3/2011 5:34 PM To: Parthasarathi R (partr); Ken Rehor (krehor); siprec@ietf.org Subject: RE: [siprec] draft-ietf-siprec-req-06 posted Partha, Hi I am not sure about removing. It is requirement level document and how to i= mplement it either via policy In case of policy, there is no need of configuration and metadata indication it is more protocol level decision. As per the last meeting, the information is not passed in metadata= model. If required, we need to revisit the metada Partha> >From my point of view it is also two separate flows: indicating retention p= arameters or immediate stop of the recording. The requirement wordings does not look like stop of the recording.= The intention is to cancel and discard the existing recording of specific = RS For example, SRC for some reason wants to cancel recording, the best way wi= ll be to send BYE with specific error code and not metadata update event. I agree that different way to achieve it in SIPREC solution. Metad= ata model composes of all recording related sig between between SRS and SRC= . As part of SIPREC solution, We may decide to use error code in BYE to can= cel and discard recording but we have to represent it in the metadata model= . Please let me know your opinion here. Regards Leon From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Parthasarathi R (partr) Sent: Monday, January To: Ken Rehor (krehor); siprec@ietf.org Subject: Re: [siprec] draft-ietf-siprec-req-06 posted Ken and all, During the last interim meeting, it was decided to put the "forced deletion= " attribute in the appdata of Metadata model instead of including in the mo= del. Cancel and discard recording from SRC is considered as policy mechanis= m passing to SRS. If so, the following requirements has to be removed from = SIPREC requirement: o REQ-015: The mechanism MUST support a means to bsp; the recording and= associated metadata for a CS. o REQ-016: The mechanism MUST support a means to cancel and discard the recording but not the associated metadata for a CS. Please let me know your opinion on the same. Thanks Partha ________________________________ From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Ken Rehor (krehor) Sent: Saturday, January 01, 2011 11:39 AM To: siprec@ietf.org Subject: [siprec] draft-ietf-siprec-req-06 posted - ietf-siprec-req-06 posted http://www.ietf.org/internet-drafts= /draft-ietf-siprec-req-06.txt - tracker item #61 closed - Draft and change log attached Happy New Year! Ken For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --_000_07465C1D981ABC41A344374066AE1A2C389EB6DBA2TLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with the below<= /o:p>

 

<= span style=3D'font-family:"Arial","sans-serif";color:#1F497D'>Regards<= /o:p>

 

<= span style=3D'font-family:"Arial","sans-serif";color:#1F497D'>Leon

 

From: Parthasarathi R (partr) [mailto:partr@cisco.com]
Sent:= Tuesday, January 04, 2011 8:57 AM
To: Deepanshu Gautam; Leon= Portman; Ken Rehor (krehor); siprec@ietf.org
Cc: Paul Kyzivat (p= kyzivat)
Subject: Metadata with "forced deletion" attri= bute [was RE: [siprec] draft-ietf-siprec-req-06 posted]

 

Incase everyone feels that REQ-15 and REQ-16 requirements are= required, I'm fine. I'm worried from the metadata model as we are planning= to remove "forced deletion" attribute in CS. ISTM, metadata mode= l is inconsistent w.r.t requirement.

 

IMO, we need to= add the "forced deletion" attribute in CS of meta= data model to meet REQ-15 and REQ-16 with attribute values as=

 

1) Complete

2) Media del= etion only

 

The solution document will provide the realizat= ion (like BYE with extra SIP header) for this attribute. Please let me= know your opinion on the same.

&n= bsp;

Thanks

Partha

From: Deepanshu Gautam [mailto:deepanshu@huawei.com]
Sent: T= uesday, January 04, 2011 7:50 AM
To: Parthasarathi R (partr); 'Le= on Portman'; Ken Rehor (krehor); siprec@ietf.org
Subject: RE: [si= prec] draft-ietf-siprec-req-06 posted

I think the original intention for th= ese requirements was indeed the stop of recording and/or discard any metada= ta already submitted. The word ‘cancel’ *is* implying a = stop-of-recording. You don’t cancel existing recording, you delete ex= isting/discard recording. I think the wording is fine.

 

We can add something related with “- a poli= cy at the SRS whether to honor such a request.” If we really need that at requi= rement level

< Regards

 

Deepanshu Gautam

T: +86 25 5260008 M: +86 135 85147627

&nb= sp;

From: siprec-bounces@i= etf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi = R (partr)
Sent: Tuesday, Jan To: Leon Portman; Ken Rehor (= krehor); siprec@ietf.org
Subject: Re: [siprec] draft-ietf-siprec-= req-06 posted

&n= bsp;

Le= on,

 

Please read inline.

 

Thanks

Partha

 

<= div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'>

From: Leon Portman [mailto:Leon.Portman@nice.com]
Se= nt: Mon 1/3/2011 5:34 PM
To: Parthasarathi R (partr); Ken Reh= or (krehor); siprec@ietf.org
Subject: RE: [siprec] draft-ietf-sip= rec-req-06 posted

Partha, Hi

 

I am not= sure about removing. It is requirement level document and how to implement= it either via policy

<Partha> In case= of policy, there is no need of configuration </Partha>

and metadata indication it is more protocol level decision= .

<Partha> As per the last meeting, the= information is not passed in metadata model. If required, we need to revis= it the metada Partha>

From my point of vie= w it is also two separate flows: indicating retention parameters or immedia= te stop of the recording.

<Partha> The = requirement wordings does not look like stop of the recording. The intentio= n is to cancel and discard the existing recording of specific RS </Parth= a>

For example, SRC for some reason wants = to cancel recording, the best way will be to send BYE with specific error c= ode and not metadata update event.

<Partha= > I agree that different way to achieve it in SIPREC solution. Metadata = model composes of all recording related sig between between = SRS and SRC. As part of SIPREC solution, We may decide to use error code in= BYE to cancel and discard recording but we have to represent it = in the metadata model. Please let me know your opinion here. </Part= ha>

 

Regards

 

=

Leon

 

From: siprec-bounces@ietf.org [mailto:si= prec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr)
Se= nt: Monday, January To: Ken Rehor (krehor); siprec@ietf.org
Subje= ct: Re: [siprec] draft-ietf-siprec-req-06 posted

<= /div>

 

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:blue'= >Ken and all,

 

During the last interim meeting, it was decided to= put the "forced deletion" attribute in the appdata of Metadata m= odel instead of including in the model. Cancel and discard record= ing from SRC is considered as policy mechanism passing to SRS. If so, = the following requirements has to be removed from SIPREC requirement:

 

=    o REQ-015: The mechanism MUST support a means to bsp;  th= e recording and associated metadata for a CS.

   o REQ-016= : The mechanism MUST support a means to cancel and discard
   = the recording but not the associated metadata for a CS.

Please let me know your opinion on the same.

 

Thanks

Partha=

From: siprec-bounces@ietf.org [mailto:s= iprec-bounces@ietf.org] On Behalf Of Ken Rehor (krehor)
Sent:<= /b> Saturday, January 01, 2011 11:39 AM
To: siprec@ietf.org
Subject: [siprec] draft-ietf-siprec-req-06 posted

-    &nb= sp;     ietf-siprec-req-06 posted  &nb= sp; http://www.ietf.org/internet-drafts/draft-ietf-siprec-req-06.txt<= o:p>

- &= nbsp;        tracker item #61 clo= sed

-       = ;   Draft and change log attached

 

Happy New Year!=

 

Ke= n

 

 

For corporate legal information go to:<= br>http://www.cisco.com/web/about/doing_business/legal/cri/index.html

 

= --_000_07465C1D981ABC41A344374066AE1A2C389EB6DBA2TLVMBX01nicec_-- From rmohanr@cisco.com Tue Jan 4 03:40:51 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A8103A6B63 for ; Tue, 4 Jan 2011 03:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.483 X-Spam-Level: X-Spam-Status: No, score=-10.483 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fgYKFchTRAC for ; Tue, 4 Jan 2011 03:40:42 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 780903A69B7 for ; Tue, 4 Jan 2011 03:40:42 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAGCWIk1AaMHG/2dsb2JhbACCKKIOc6FnmTOFSgSEZolE X-IronPort-AV: E=Sophos;i="4.60,271,1291593600"; d="scan'208,217";a="395940031" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-1.cisco.com with ESMTP; 04 Jan 2011 11:42:48 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p04BgdRT023421; Tue, 4 Jan 2011 11:42:45 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Jan 2011 17:12:36 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBAC04.7BAF3A25" Date: Tue, 4 Jan 2011 17:12:34 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD04E1F2BB@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Metadata with "forced deletion" attribute [was RE:draft-ietf-siprec-req-06 posted] Thread-Index: AcupemC/6QmwULhdT5CrRoSmufArYQBrQkUQAARtwRAAHIFEiAACXfOQAAiPuQAACM8G0A== References: <7744FE52C78D944587F03773EB45146109139DEE@xmb-sjc-22e.amer.cisco.com><07465C1D981ABC41A344374066AE1A2C389EB6D950@TLVMBX01.nice.com><008b01cbabb5$dfde01d0$9f9a0570$@com> From: "Ram Mohan R (rmohanr)" To: "Parthasarathi R (partr)" , "Deepanshu Gautam" , "Leon Portman" , "Ken Rehor (krehor)" , X-OriginalArrivalTime: 04 Jan 2011 11:42:36.0776 (UTC) FILETIME=[7BD78680:01CBAC04] Subject: Re: [siprec] Metadata with "forced deletion" attribute [was RE:draft-ietf-siprec-req-06 posted] X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 11:40:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBAC04.7BAF3A25 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regarding REQ-015 and REQ-016, I think we need to put some thought on how the solution will accommodate these requirements.=20 =20 There was a suggestion to indicate force deletion in BYE with specific error codes. I see issues with that. How will this work for persistent recording session cases where you don't want to disconnect the RS ? Also this will not be useful if we want to discard the metadata/recorded media of one (OR a subset) of participants only. Also I am not inclined to see specific SIP error codes for indicating recording attributes. If it is really needed to indicate its better done through Recording metadata ( in XML). =20 If we are to support indication of force deletion from SRC to SRS, how does the SRC gets to know this information ? Is it through some policy configured at SRC ? If its policy, IMO the policy could as well be applied directly at SRS. =20 Or is it through user input ? If it's through user input how is this communicated to SRC[ in case SRC happens to be B2BUA] ? =20 Regards, Ram =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) Sent: Tuesday, January 04, 2011 12:27 PM To: Deepanshu Gautam; Leon Portman; Ken Rehor (krehor); siprec@ietf.org Subject: [siprec] Metadata with "forced deletion" attribute [was RE:draft-ietf-siprec-req-06 posted] =20 Incase everyone feels that REQ-15 and REQ-16 requirements are required, I'm fine. I'm worried from the metadata model as we are planning to remove "forced deletion" attribute in CS. ISTM, metadata model is inconsistent w.r.t requirement.=20 =20 IMO, we need to add the "forced deletion" attribute in CS of metadata model to meet REQ-15 and REQ-16 with attribute values as =20 1) Complete 2) Media deletion only =20 The solution document will provide the realization (like BYE with extra SIP header) for this attribute. Please let me know your opinion on the same. =20 Thanks Partha ________________________________ From: Deepanshu Gautam [mailto:deepanshu@huawei.com]=20 Sent: Tuesday, January 04, 2011 7:50 AM To: Parthasarathi R (partr); 'Leon Portman'; Ken Rehor (krehor); siprec@ietf.org Subject: RE: [siprec] draft-ietf-siprec-req-06 posted I think the original intention for these requirements was indeed the stop of recording and/or discard any metadata already submitted. The word 'cancel' *is* implying a stop-of-recording. You don't cancel existing recording, you delete existing/discard recording. I think the wording is fine. =20 We can add something related with "- a policy at the SRS whether to honor such a request." If we really need that at requirement level < Regards =20 Deepanshu Gautam T: +86 25 5260008 M: +86 135 85147627 =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) Sent: Tuesday, Jan To: Leon Portman; Ken Rehor (krehor); siprec@ietf.org Subject: Re: [siprec] draft-ietf-siprec-req-06 posted =20 Leon, =20 Please read inline. =20 Thanks Partha =20 ________________________________ From: Leon Portman [mailto:Leon.Portman@nice.com] Sent: Mon 1/3/2011 5:34 PM To: Parthasarathi R (partr); Ken Rehor (krehor); siprec@ietf.org Subject: RE: [siprec] draft-ietf-siprec-req-06 posted Partha, Hi =20 I am not sure about removing. It is requirement level document and how to implement it either via policy=20 In case of policy, there is no need of configuration and metadata indication it is more protocol level decision. As per the last meeting, the information is not passed in metadata model. If required, we need to revisit the metada Partha> >From my point of view it is also two separate flows: indicating retention parameters or immediate stop of the recording. The requirement wordings does not look like stop of the recording. The intention is to cancel and discard the existing recording of specific RS For example, SRC for some reason wants to cancel recording, the best way will be to send BYE with specific error code and not metadata update event. I agree that different way to achieve it in SIPREC solution. Metadata model composes of all recording related sig between between SRS and SRC. As part of SIPREC solution, We may decide to use error code in BYE to cancel and discard recording but we have to represent it in the metadata model. Please let me know your opinion here. =20 Regards =20 Leon =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) Sent: Monday, January To: Ken Rehor (krehor); siprec@ietf.org Subject: Re: [siprec] draft-ietf-siprec-req-06 posted =20 Ken and all, =20 During the last interim meeting, it was decided to put the "forced deletion" attribute in the appdata of Metadata model instead of including in the model. Cancel and discard recording from SRC is considered as policy mechanism passing to SRS. If so, the following requirements has to be removed from SIPREC requirement: =20 o REQ-015: The mechanism MUST support a means to bsp; the recording and associated metadata for a CS. o REQ-016: The mechanism MUST support a means to cancel and discard the recording but not the associated metadata for a CS. Please let me know your opinion on the same. =20 Thanks Partha ________________________________ From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ken Rehor (krehor) Sent: Saturday, January 01, 2011 11:39 AM To: siprec@ietf.org Subject: [siprec] draft-ietf-siprec-req-06 posted - ietf-siprec-req-06 posted http://www.ietf.org/internet-drafts/draft-ietf-siprec-req-06.txt - tracker item #61 closed - Draft and change log attached =20 Happy New Year! =20 Ken =20 =20 For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 ------_=_NextPart_001_01CBAC04.7BAF3A25 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Regarding  REQ-015 and REQ-016, I think we = need to put some thought on how the solution will  accommodate = these requirements.

 

There was a suggestion = to indicate force deletion in BYE with specific error codes.  I see = issues with that. How will this work for persistent recording session = cases where you don’t want to disconnect the RS ? Also  this = will not be useful if we want to discard the metadata/recorded media of = one (OR a subset) of participants only.  Also I am not inclined to = see specific SIP error codes for indicating recording attributes. If it = is really needed to indicate its better done through Recording metadata = ( in XML).

 

If we are to support = indication of force deletion from SRC to SRS,  how does the SRC = gets to know this information ?   Is it through some policy = configured at SRC ?  If its policy, IMO the policy could as well be = applied directly at SRS.

 

Or is it through user = input ? If it’s through user input how is this communicated to = SRC[ in case SRC happens to be B2BUA] ?

 

Regards,

Ram

 

From:= = siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Parthasarathi R (partr)
Sent: Tuesday, January 04, 2011 = 12:27 PM
To: Deepanshu Gautam; Leon Portman; Ken Rehor = (krehor); siprec@ietf.org
Subject: [siprec] Metadata with = "forced deletion" attribute [was RE:draft-ietf-siprec-req-06 = posted]

 

In= case everyone feels that REQ-15 and REQ-16 requirements are = required, I'm fine. I'm worried from the metadata model as we are = planning to remove "forced deletion" attribute in CS. ISTM, = metadata model is inconsistent w.r.t requirement.

 

IM= O, we need to add the "forced deletion" attribute in = CS of metadata model to meet REQ-15 and REQ-16 with attribute = values as

 

1)= Complete

2)= Media deletion only

 

Th= e solution document will provide the realization (like BYE with extra = SIP header) for this attribute. Please let me know your opinion on = the same.

 

Th= anks

Pa= rtha

From:= = Deepanshu Gautam [mailto:deepanshu@huawei.com]
Sent: Tuesday, = January 04, 2011 7:50 AM
To: Parthasarathi R (partr); 'Leon = Portman'; Ken Rehor (krehor); siprec@ietf.org
Subject: RE: = [siprec] draft-ietf-siprec-req-06 posted

I think the original intention for these = requirements was indeed the stop of recording and/or discard any = metadata already submitted. The word ‘cancel’ *is* = implying a stop-of-recording. You don’t cancel existing recording, = you delete existing/discard recording. I think the wording is = fine.

 

We can add = something related with “- a policy at the SRS whether to = honor such a request.” If we = really need that at requirement level

< Regards

 

Deepanshu Gautam

T: +86 25 5260008 M: +86 135 85147627

 

From:= = siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Parthasarathi R (partr)
Sent: Tuesday, Jan To: Leon = Portman; Ken Rehor (krehor); siprec@ietf.org
Subject: Re: = [siprec] draft-ietf-siprec-req-06 = posted

 

L= eon,

 

Please read = inline.

 

Thanks

Partha=

 

From:= = Leon Portman [mailto:Leon.Portman@nice.com]
Sent: Mon 1/3/2011 = 5:34 PM
To: Parthasarathi R (partr); Ken Rehor (krehor); = siprec@ietf.org
Subject: RE: [siprec] draft-ietf-siprec-req-06 = posted

Partha, = Hi

 

I am not sure = about removing. It is requirement level document and how to implement it = either via policy

<Partha> = In case of policy, there is no need of configuration = </Partha>

and metadata = indication it is more protocol level decision.

<Partha> = As per the last meeting, the information is not passed in metadata = model. If required, we need to revisit the metada = Partha>

From my point = of view it is also two separate flows: indicating retention parameters = or immediate stop of the recording.

<Partha> = The requirement wordings does not look like stop of the recording. The = intention is to cancel and discard the existing recording of specific RS = </Partha>

For example, = SRC for some reason wants to cancel recording, the best way will be to = send BYE with specific error code and not metadata update = event.

<Partha> = I agree that different way to achieve it in SIPREC solution. Metadata = model composes of all recording related sig = between between SRS and SRC. As part of SIPREC solution, We may = decide to use error code in BYE to cancel and discard = recording but we have to represent it in the metadata model. Please = let me know your opinion = here. </Partha>

 

Regards

 

Leon=

 

From:= = siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Parthasarathi R (partr)
Sent: Monday, January To: Ken = Rehor (krehor); siprec@ietf.org
Subject: Re: [siprec] = draft-ietf-siprec-req-06 posted

 

Ke= n and all,

 

Du= ring the last interim meeting, it was decided to put the "forced = deletion" attribute in the appdata of Metadata model instead of = including in the model. Cancel and discard recording from SRC = is considered as policy mechanism passing to SRS. If so, the = following requirements has to be removed from SIPREC = requirement:

 

   o REQ-015: The mechanism MUST support a = means to bsp;  the recording and associated metadata for a = CS.

   o REQ-016: The mechanism MUST support a means to = cancel and discard
   the recording but not the associated = metadata for a CS.

Pl= ease let me know your opinion on the same.

 

Th= anks

Pa= rtha

From:= siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On = Behalf Of Ken Rehor (krehor)
Sent: Saturday, January 01, = 2011 11:39 AM
To: siprec@ietf.org
Subject: [siprec] = draft-ietf-siprec-req-06 posted

-          = ietf-siprec-req-06 posted    http://www.ietf.org/internet-drafts/draft-ietf-siprec-req-06.txt

-          = tracker item #61 closed

-        = ;  Draft and change log attached

 

Happy New = Year!

 

Ken

 

 

For corporate = legal information go = to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 

------_=_NextPart_001_01CBAC04.7BAF3A25-- From partr@cisco.com Tue Jan 4 03:50:48 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFF943A6BA6 for ; Tue, 4 Jan 2011 03:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.081 X-Spam-Level: X-Spam-Status: No, score=-10.081 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WnvYWfCV-HW for ; Tue, 4 Jan 2011 03:50:45 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 261CD3A6B7F for ; Tue, 4 Jan 2011 03:50:45 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACeZIk1AaMHG/2dsb2JhbACkNnOhWJkzhUoEhGaJRA X-IronPort-AV: E=Sophos;i="4.60,271,1291593600"; d="scan'208";a="254065783" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-3.cisco.com with ESMTP; 04 Jan 2011 11:52:51 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p04BqR2k024742; Tue, 4 Jan 2011 11:52:50 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Jan 2011 17:22:33 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Jan 2011 17:22:33 +0530 Message-ID: In-Reply-To: <4D21F2B6.8030304@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] draft-ietf-siprec-req-06 posted Thread-Index: AcurX2xpNpAitU0nQfmvmaf2MOexJAAo9+dA References: <7744FE52C78D944587F03773EB45146109139DEE@xmb-sjc-22e.amer.cisco.com> <07465C1D981ABC41A344374066AE1A2C389EB6D950@TLVMBX01.nice.com> <4D21F2B6.8030304@cisco.com> From: "Parthasarathi R (partr)" To: "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 04 Jan 2011 11:52:33.0893 (UTC) FILETIME=[DFC05950:01CBAC05] Subject: Re: [siprec] draft-ietf-siprec-req-06 posted X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 11:50:49 -0000 Paul, Please read inline. Thanks Partha=20 -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) Sent: Monday, January 03, 2011 9:31 PM To: siprec@ietf.org Subject: Re: [siprec] draft-ietf-siprec-req-06 posted ISTM there are two parts to this: - a mechanism for the SRC to indicate its desire to stop/cancel the recording and discard the media and/or metadata. - a policy at the SRS whether to honor such a request. As Deepanshu mentioned in another mail thread, there is no specific requirement for SRS handling but I'm not sure whether there is an need for explicit requirement The requirements aren't phrased that way. If they were, would it satisfy everybody? Thanks, Paul On 1/3/2011 7:04 AM, Leon Portman wrote: > Partha, Hi > > I am not sure about removing. It is requirement level document and how > to implement it either via policy and metadata indication it is more=20 > protocol level decision. > > From my point of view it is also two separate flows: indicating=20 > retention parameters or immediate stop of the recording. > > For example, SRC for some reason wants to cancel recording, the best=20 > way will be to send BYE with specific error code and not metadata update event. > > Regards > > Leon > > *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On=20 > Behalf Of *Parthasarathi R (partr) > *Sent:* Monday, January 03, 2011 11:24 AM > *To:* Ken Rehor (krehor); siprec@ietf.org > *Subject:* Re: [siprec] draft-ietf-siprec-req-06 posted > > Ken and all, > > During the last interim meeting, it was decided to put the "forced=20 > deletion" attribute in the appdata of Metadata model instead of=20 > including in the model. Cancel and discard recording from SRC is=20 > considered as policy mechanism passing to SRS. If so, the following=20 > requirements has to be removed from SIPREC requirement: > > o REQ-015: The mechanism MUST support a means to cancel and discard=20 > the recording and associated metadata for a CS. > > o REQ-016: The mechanism MUST support a means to cancel and discard=20 > the recording but not the associated metadata for a CS. > > Please let me know your opinion on the same. > > Thanks > > Partha > > ---------------------------------------------------------------------- > -- > > *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On=20 > Behalf Of *Ken Rehor (krehor) > *Sent:* Saturday, January 01, 2011 11:39 AM > *To:* siprec@ietf.org > *Subject:* [siprec] draft-ietf-siprec-req-06 posted > > -ietf-siprec-req-06 posted > http://www.ietf.org/internet-drafts/draft-ietf-siprec-req-06.txt > > -tracker item #61 closed > > -Draft and change log attached > > Happy New Year! > > Ken > > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > 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 From andrew.hutton@siemens-enterprise.com Wed Jan 5 02:53:30 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9FCE3A6B79 for ; Wed, 5 Jan 2011 02:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egrlNojdFx4E for ; Wed, 5 Jan 2011 02:53:29 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 4DE773A6B76 for ; Wed, 5 Jan 2011 02:53:29 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2896232; Wed, 5 Jan 2011 11:55:28 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 628221EB82B4; Wed, 5 Jan 2011 11:55:28 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 5 Jan 2011 11:55:28 +0100 From: "Hutton, Andrew" To: Paul Kyzivat , "siprec@ietf.org" Date: Wed, 5 Jan 2011 11:55:27 +0100 Thread-Topic: [siprec] Participant role parameter in Metadata model Thread-Index: AcurXtEzhjm56jp0QrirUNESYYJ+cgBZcNTw Message-ID: <101C6067BEC68246B0C3F6843BCCC1E309B382B996@MCHP058A.global-ad.net> References: <4D21F1B3.3060301@cisco.com> In-Reply-To: <4D21F1B3.3060301@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Participant role parameter in Metadata model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 10:53:30 -0000 I agree with Paul that this needs some thought. I suspect that the SRS does not need information about who is the uac or ua= s for a given SIP transaction but will want to know the role of each partic= ipant with regard to the session. For example who is the calling/called par= ties (i.e. who was the uac for the initial dialog creating INVITE).=20 The SRS may also need information about who initiates any additional media = streams during a session but I am not sure about this. The requirements are not much help as we only have REQ-12 which states: "The mechanism MUST provide the SRS with metadata describing CSs that are b= eing recorded, including the media being used and the identities of parties= involved". Regards Andy =20 -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: 03 January 2011 15:57 To: siprec@ietf.org Subject: Re: [siprec] Participant role parameter in Metadata model On 1/3/2011 6:53 AM, Parthasarathi R (partr) wrote: > Hi all, > From the current metadata parameters, it is not possible for SRS to > deduce whether the participant is acting as "uac" or "uas" for a given > transaction in CS but SRC is aware of this information in most of the > scenarios. Participant role information in CS will be lost as RS is not > carry this information as part of metadata. IMO, it is better to add > this information as participant role with value as "uac" or "uas" or > "don't know" in the metadata. > This information helps to understand who initiated the dialog from SRS > perspective in case SRS has more configuration/metadata information > about the participant. Please let me know whether it is worth to add > this information as part of participant metadata information. > Thanks > Partha Its at least going to take some thought to get this right. The metadata we have defined isn't really structured transactionally the=20 same way sip is. Its more "declarative" than operational. So for instance, there might be a metadata change that adds an=20 additional media stream. There may have been multiple sip transactions=20 take place to negotiate that new media stream. One specific participant=20 may have sent the first transaction that initiated an o/a negotiation=20 that resulted in the new media stream. But its possible the the first=20 offer of that stream came from a different participant. Now, perhaps there is some interest in recording all, or a summary, of=20 all the sip traffic on the CS as part of the metadata. But that is=20 likely to be overkill. If not, then I think roles such as UAC and UAS=20 need to be translated into something that makes sense in the metadata.=20 I'm not entirely sure what that would be - it varies for different=20 pieces of the metadata. Thanks, Paul > _______________________________________________ > 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 From srao@ctigroup.com Wed Jan 5 05:34:10 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C061A3A6C05 for ; Wed, 5 Jan 2011 05:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLJAgcm2jVYN for ; Wed, 5 Jan 2011 05:34:09 -0800 (PST) Received: from EXCHANGE2K3.ctigroup.com (etomernpv.ctigroup.com [64.132.87.194]) by core3.amsl.com (Postfix) with ESMTP id 92C173A6D3C for ; Wed, 5 Jan 2011 05:34:09 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Jan 2011 08:36:11 -0500 Message-ID: In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E309B382B996@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Participant role parameter in Metadata model Thread-Index: AcurXtEzhjm56jp0QrirUNESYYJ+cgBZcNTwAAY77ns= From: "Sid Rao" To: , , Subject: Re: [siprec] Participant role parameter in Metadata model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 13:34:11 -0000 Ideally, there would be additional data about the call (redirection, for = example), with the ability to provide additional ancillary custom data. Sid Rao - Chief Technology Officer - CTI Group, Inc. - +1 (317) 262-4677 ----- Original Message ----- From: siprec-bounces@ietf.org To: Paul Kyzivat ; siprec@ietf.org Sent: Wed Jan 05 05:55:27 2011 Subject: Re: [siprec] Participant role parameter in Metadata model I agree with Paul that this needs some thought. I suspect that the SRS does not need information about who is the uac or = uas for a given SIP transaction but will want to know the role of each = participant with regard to the session. For example who is the = calling/called parties (i.e. who was the uac for the initial dialog = creating INVITE).=20 The SRS may also need information about who initiates any additional = media streams during a session but I am not sure about this. The requirements are not much help as we only have REQ-12 which states: "The mechanism MUST provide the SRS with metadata describing CSs that = are being recorded, including the media being used and the identities of = parties involved". Regards Andy =20 -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf = Of Paul Kyzivat Sent: 03 January 2011 15:57 To: siprec@ietf.org Subject: Re: [siprec] Participant role parameter in Metadata model On 1/3/2011 6:53 AM, Parthasarathi R (partr) wrote: > Hi all, > From the current metadata parameters, it is not possible for SRS to > deduce whether the participant is acting as "uac" or "uas" for a given > transaction in CS but SRC is aware of this information in most of the > scenarios. Participant role information in CS will be lost as RS is = not > carry this information as part of metadata. IMO, it is better to add > this information as participant role with value as "uac" or "uas" or > "don't know" in the metadata. > This information helps to understand who initiated the dialog from SRS > perspective in case SRS has more configuration/metadata information > about the participant. Please let me know whether it is worth to add > this information as part of participant metadata information. > Thanks > Partha Its at least going to take some thought to get this right. The metadata we have defined isn't really structured transactionally the = same way sip is. Its more "declarative" than operational. So for instance, there might be a metadata change that adds an=20 additional media stream. There may have been multiple sip transactions=20 take place to negotiate that new media stream. One specific participant=20 may have sent the first transaction that initiated an o/a negotiation=20 that resulted in the new media stream. But its possible the the first=20 offer of that stream came from a different participant. Now, perhaps there is some interest in recording all, or a summary, of=20 all the sip traffic on the CS as part of the metadata. But that is=20 likely to be overkill. If not, then I think roles such as UAC and UAS=20 need to be translated into something that makes sense in the metadata.=20 I'm not entirely sure what that would be - it varies for different=20 pieces of the metadata. Thanks, Paul > _______________________________________________ > 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 ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email=20 ______________________________________________________________________ From pkyzivat@cisco.com Wed Jan 5 12:02:02 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75A083A6CFF for ; Wed, 5 Jan 2011 12:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.472 X-Spam-Level: X-Spam-Status: No, score=-110.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxBf3zQlNxdm for ; Wed, 5 Jan 2011 12:02:01 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 09AF03A6CBB for ; Wed, 5 Jan 2011 12:01:40 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAddJE1AZnwM/2dsb2JhbACkG3OnC5gogn+CTQSEaIYigx8 X-IronPort-AV: E=Sophos;i="4.60,279,1291593600"; d="scan'208";a="200319187" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 05 Jan 2011 20:03:47 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p05K3ljI028884; Wed, 5 Jan 2011 20:03:47 GMT Message-ID: <4D24CEA3.70803@cisco.com> Date: Wed, 05 Jan 2011 15:03:47 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Hutton, Andrew" References: <4D21F1B3.3060301@cisco.com> <101C6067BEC68246B0C3F6843BCCC1E309B382B996@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E309B382B996@MCHP058A.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Participant role parameter in Metadata model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 20:02:02 -0000 On 1/5/2011 5:55 AM, Hutton, Andrew wrote: > > I agree with Paul that this needs some thought. > > I suspect that the SRS does not need information about who is the uac or uas for a given SIP transaction but will want to know the role of each participant with regard to the session. For example who is the calling/called parties (i.e. who was the uac for the initial dialog creating INVITE). > > The SRS may also need information about who initiates any additional media streams during a session but I am not sure about this. For this, we will need to be specific about what it means to initiate a media stream. For instance: - is it a participant who offered a stream that wasn't yet in the session? - does it matter what "direction" was offered? (If a participant offers the stream, but in recvonly mode, is it still the originator? - what about changes to an existing stream? E.g. if a reinvite offers a codec change on a stream that was initiated by a different participant, does that mean a new replacement stream originated by the new offerer? - what if an existing stream is replaced by a totally different stream. (This is allowed, but kind of unusual.) For instance an audio stream could be replaced by a t38 fax stream. Thanks, Paul > The requirements are not much help as we only have REQ-12 which states: > > "The mechanism MUST provide the SRS with metadata describing CSs that are being recorded, including the media being used and the identities of parties involved". > > Regards > Andy > > > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 03 January 2011 15:57 > To: siprec@ietf.org > Subject: Re: [siprec] Participant role parameter in Metadata model > > > > On 1/3/2011 6:53 AM, Parthasarathi R (partr) wrote: >> Hi all, >> From the current metadata parameters, it is not possible for SRS to >> deduce whether the participant is acting as "uac" or "uas" for a given >> transaction in CS but SRC is aware of this information in most of the >> scenarios. Participant role information in CS will be lost as RS is not >> carry this information as part of metadata. IMO, it is better to add >> this information as participant role with value as "uac" or "uas" or >> "don't know" in the metadata. >> This information helps to understand who initiated the dialog from SRS >> perspective in case SRS has more configuration/metadata information >> about the participant. Please let me know whether it is worth to add >> this information as part of participant metadata information. >> Thanks >> Partha > > Its at least going to take some thought to get this right. > The metadata we have defined isn't really structured transactionally the > same way sip is. Its more "declarative" than operational. > > So for instance, there might be a metadata change that adds an > additional media stream. There may have been multiple sip transactions > take place to negotiate that new media stream. One specific participant > may have sent the first transaction that initiated an o/a negotiation > that resulted in the new media stream. But its possible the the first > offer of that stream came from a different participant. > > Now, perhaps there is some interest in recording all, or a summary, of > all the sip traffic on the CS as part of the metadata. But that is > likely to be overkill. If not, then I think roles such as UAC and UAS > need to be translated into something that makes sense in the metadata. > I'm not entirely sure what that would be - it varies for different > pieces of the metadata. > > Thanks, > Paul > >> _______________________________________________ >> 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 > From Henry.Lum@alcatel-lucent.com Wed Jan 5 12:09:44 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFA5A3A6CBB for ; Wed, 5 Jan 2011 12:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.784 X-Spam-Level: X-Spam-Status: No, score=-5.784 tagged_above=-999 required=5 tests=[AWL=0.815, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56BA9FC3HJtj for ; Wed, 5 Jan 2011 12:09:43 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 588043A6C78 for ; Wed, 5 Jan 2011 12:09:43 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p05KBeKs027612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Jan 2011 14:11:40 -0600 (CST) Received: from relay-out2.dc (relay-out2.dc.genesyslab.com [172.22.68.188]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p05KBcOh015821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Jan 2011 14:11:40 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc (8.13.8+Sun/8.13.8) with ESMTP id p05KBbxa006126; Wed, 5 Jan 2011 12:11:38 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Jan 2011 12:11:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Jan 2011 12:11:36 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF740688C27E@NAHALD.us.int.genesyslab.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Participant role parameter in Metadata model Thread-Index: AcurXtEzhjm56jp0QrirUNESYYJ+cgBZcNTwAAY77nsADUNOMA== References: <101C6067BEC68246B0C3F6843BCCC1E309B382B996@MCHP058A.global-ad.net> From: "Henry Lum" To: "Sid Rao" , , , X-OriginalArrivalTime: 05 Jan 2011 20:11:37.0887 (UTC) FILETIME=[C22CFAF0:01CBAD14] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [siprec] Participant role parameter in Metadata model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 20:09:44 -0000 I agree the wording for uac and uas may be a bit too technical or too raw and it can be confusing to interpret what it really means. For example, if a caller uses a 3pcc application to place a call to a callee, the 3pcc app would place two SIP dialogs to the caller and callee and join them together, and you will end up with two uas parties which can be difficult to interpret the result.=20 Ideally I think it should be something like calling party or called party. If the SRC understands how to interpret the party role then it can record it in the metadata. Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Sid Rao > Sent: Wednesday, January 05, 2011 8:36 AM > To: andrew.hutton@siemens-enterprise.com; pkyzivat@cisco.com; > siprec@ietf.org > Subject: Re: [siprec] Participant role parameter in Metadata model >=20 > Ideally, there would be additional data about the call (redirection, > for example), with the ability to provide additional ancillary custom > data. >=20 > Sid Rao - Chief Technology Officer - CTI Group, Inc. - +1 (317) 262- > 4677 >=20 > ----- Original Message ----- > From: siprec-bounces@ietf.org > To: Paul Kyzivat ; siprec@ietf.org > > Sent: Wed Jan 05 05:55:27 2011 > Subject: Re: [siprec] Participant role parameter in Metadata model >=20 >=20 > I agree with Paul that this needs some thought. >=20 > I suspect that the SRS does not need information about who is the uac > or uas for a given SIP transaction but will want to know the role of > each participant with regard to the session. For example who is the > calling/called parties (i.e. who was the uac for the initial dialog > creating INVITE). >=20 > The SRS may also need information about who initiates any additional > media streams during a session but I am not sure about this. >=20 > The requirements are not much help as we only have REQ-12 which states: >=20 > "The mechanism MUST provide the SRS with metadata describing CSs that > are being recorded, including the media being used and the identities > of parties involved". >=20 > Regards > Andy >=20 >=20 >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 03 January 2011 15:57 > To: siprec@ietf.org > Subject: Re: [siprec] Participant role parameter in Metadata model >=20 >=20 >=20 > On 1/3/2011 6:53 AM, Parthasarathi R (partr) wrote: > > Hi all, > > From the current metadata parameters, it is not possible for SRS to > > deduce whether the participant is acting as "uac" or "uas" for a > given > > transaction in CS but SRC is aware of this information in most of the > > scenarios. Participant role information in CS will be lost as RS is > not > > carry this information as part of metadata. IMO, it is better to add > > this information as participant role with value as "uac" or "uas" or > > "don't know" in the metadata. > > This information helps to understand who initiated the dialog from > SRS > > perspective in case SRS has more configuration/metadata information > > about the participant. Please let me know whether it is worth to add > > this information as part of participant metadata information. > > Thanks > > Partha >=20 > Its at least going to take some thought to get this right. > The metadata we have defined isn't really structured transactionally > the > same way sip is. Its more "declarative" than operational. >=20 > So for instance, there might be a metadata change that adds an > additional media stream. There may have been multiple sip transactions > take place to negotiate that new media stream. One specific participant > may have sent the first transaction that initiated an o/a negotiation > that resulted in the new media stream. But its possible the the first > offer of that stream came from a different participant. >=20 > Now, perhaps there is some interest in recording all, or a summary, of > all the sip traffic on the CS as part of the metadata. But that is > likely to be overkill. If not, then I think roles such as UAC and UAS > need to be translated into something that makes sense in the metadata. > I'm not entirely sure what that would be - it varies for different > pieces of the metadata. >=20 > Thanks, > Paul >=20 > > _______________________________________________ > > 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 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From srao@ctigroup.com Wed Jan 5 12:16:24 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A5803A6CEC for ; Wed, 5 Jan 2011 12:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7CkH0EBasOD for ; Wed, 5 Jan 2011 12:16:22 -0800 (PST) Received: from EXCHANGE2K3.ctigroup.com (etomernpv.ctigroup.com [64.132.87.194]) by core3.amsl.com (Postfix) with ESMTP id A8C5E3A6C78 for ; Wed, 5 Jan 2011 12:16:22 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Jan 2011 15:18:24 -0500 Message-ID: In-Reply-To: <059AF07365DC474393A19A3AF187DF740688C27E@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Participant role parameter in Metadata model Thread-Index: AcurXtEzhjm56jp0QrirUNESYYJ+cgBZcNTwAAY77nsADUNOMAAAlotw References: <101C6067BEC68246B0C3F6843BCCC1E309B382B996@MCHP058A.global-ad.net> <059AF07365DC474393A19A3AF187DF740688C27E@NAHALD.us.int.genesyslab.com> From: "Sid Rao" To: "Henry Lum" , , , Subject: Re: [siprec] Participant role parameter in Metadata model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 20:16:24 -0000 The challenge I see is that in real-world applications of this specification, UAC to UAS is not descriptive enough for real-world call center supervisors and financial regulatory authorities to truly find and recognize a call. As you note, in the 3PCC scenario noted below, 2 recordings of essentially an identical conversation from an end-user perspective. Another scenario, which is a typical use case, is cradle-to-grave recording scenarios. UAC to UAS conversations represent, in effect, in a B2BUA environment individual conversation legs. However, in cradle-to-grave scenarios, we would need a mechanism to relate all related UAC to UAS calls into a single presentable call. If the metadata model included a concept of diversion (transfer) or a "global call ID" this could be accommodated. Forgive me if I'm mistaken, but I did not see this accommodated in the requirements. Otherwise we risk the specification being less functional than existing solutions, reducing the motivation for adoption and compliance. Best Regards, Sid Rao -----Original Message----- From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com]=20 Sent: Wednesday, January 05, 2011 3:12 PM To: Sid Rao; andrew.hutton@siemens-enterprise.com; pkyzivat@cisco.com; siprec@ietf.org Subject: RE: [siprec] Participant role parameter in Metadata model I agree the wording for uac and uas may be a bit too technical or too raw and it can be confusing to interpret what it really means. For example, if a caller uses a 3pcc application to place a call to a callee, the 3pcc app would place two SIP dialogs to the caller and callee and join them together, and you will end up with two uas parties which can be difficult to interpret the result.=20 Ideally I think it should be something like calling party or called party. If the SRC understands how to interpret the party role then it can record it in the metadata. Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Sid Rao > Sent: Wednesday, January 05, 2011 8:36 AM > To: andrew.hutton@siemens-enterprise.com; pkyzivat@cisco.com;=20 > siprec@ietf.org > Subject: Re: [siprec] Participant role parameter in Metadata model >=20 > Ideally, there would be additional data about the call (redirection,=20 > for example), with the ability to provide additional ancillary custom=20 > data. >=20 > Sid Rao - Chief Technology Officer - CTI Group, Inc. - +1 (317) 262- > 4677 >=20 > ----- Original Message ----- > From: siprec-bounces@ietf.org > To: Paul Kyzivat ; siprec@ietf.org=20 > > Sent: Wed Jan 05 05:55:27 2011 > Subject: Re: [siprec] Participant role parameter in Metadata model >=20 >=20 > I agree with Paul that this needs some thought. >=20 > I suspect that the SRS does not need information about who is the uac=20 > or uas for a given SIP transaction but will want to know the role of=20 > each participant with regard to the session. For example who is the=20 > calling/called parties (i.e. who was the uac for the initial dialog=20 > creating INVITE). >=20 > The SRS may also need information about who initiates any additional=20 > media streams during a session but I am not sure about this. >=20 > The requirements are not much help as we only have REQ-12 which states: >=20 > "The mechanism MUST provide the SRS with metadata describing CSs that=20 > are being recorded, including the media being used and the identities=20 > of parties involved". >=20 > Regards > Andy >=20 >=20 >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Paul Kyzivat > Sent: 03 January 2011 15:57 > To: siprec@ietf.org > Subject: Re: [siprec] Participant role parameter in Metadata model >=20 >=20 >=20 > On 1/3/2011 6:53 AM, Parthasarathi R (partr) wrote: > > Hi all, > > From the current metadata parameters, it is not possible for SRS to > > deduce whether the participant is acting as "uac" or "uas" for a > given > > transaction in CS but SRC is aware of this information in most of the > > scenarios. Participant role information in CS will be lost as RS is > not > > carry this information as part of metadata. IMO, it is better to add > > this information as participant role with value as "uac" or "uas" or > > "don't know" in the metadata. > > This information helps to understand who initiated the dialog from > SRS > > perspective in case SRS has more configuration/metadata information=20 > > about the participant. Please let me know whether it is worth to add > > this information as part of participant metadata information. > > Thanks > > Partha >=20 > Its at least going to take some thought to get this right. > The metadata we have defined isn't really structured transactionally=20 > the same way sip is. Its more "declarative" than operational. >=20 > So for instance, there might be a metadata change that adds an=20 > additional media stream. There may have been multiple sip transactions > take place to negotiate that new media stream. One specific participant > may have sent the first transaction that initiated an o/a negotiation=20 > that resulted in the new media stream. But its possible the the first=20 > offer of that stream came from a different participant. >=20 > Now, perhaps there is some interest in recording all, or a summary, of > all the sip traffic on the CS as part of the metadata. But that is=20 > likely to be overkill. If not, then I think roles such as UAC and UAS=20 > need to be translated into something that makes sense in the metadata. > I'm not entirely sure what that would be - it varies for different=20 > pieces of the metadata. >=20 > Thanks, > Paul >=20 > > _______________________________________________ > > 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 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email=20 > ______________________________________________________________________ > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec =09 ------------------------------------------------------------------------ ------------------------------------------- CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities. =09 ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From Henry.Lum@alcatel-lucent.com Wed Jan 5 13:33:49 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 027AB3A6DD4 for ; Wed, 5 Jan 2011 13:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.858 X-Spam-Level: X-Spam-Status: No, score=-5.858 tagged_above=-999 required=5 tests=[AWL=0.741, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5Z1Z2esv+fR for ; Wed, 5 Jan 2011 13:33:47 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id BA5F53A6D28 for ; Wed, 5 Jan 2011 13:33:46 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p05LZiOZ021508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Jan 2011 15:35:44 -0600 (CST) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [172.22.70.114]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p05LZgT3032599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Jan 2011 15:35:44 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.wc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id p05LZhYD029111; Wed, 5 Jan 2011 13:35:43 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Jan 2011 13:35:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Jan 2011 13:35:37 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF740688C2F6@NAHALD.us.int.genesyslab.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Participant role parameter in Metadata model Thread-Index: AcurXtEzhjm56jp0QrirUNESYYJ+cgBZcNTwAAY77nsADUNOMAAAlotwAALAFzA= References: <101C6067BEC68246B0C3F6843BCCC1E309B382B996@MCHP058A.global-ad.net> <059AF07365DC474393A19A3AF187DF740688C27E@NAHALD.us.int.genesyslab.com> From: "Henry Lum" To: "Sid Rao" , , , X-OriginalArrivalTime: 05 Jan 2011 21:35:42.0027 (UTC) FILETIME=[80B7A9B0:01CBAD20] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [siprec] Participant role parameter in Metadata model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 21:33:49 -0000 For cradle-to-grave scenarios, the SRC may choose to use a CS group to represent a series of call transfers to different parties in the call, where each transfer may be considered a separate CS. There is a use case outlined in the metadata draft to describe such scenario (use case 3). Regards, Henry > -----Original Message----- > From: Sid Rao [mailto:srao@ctigroup.com] > Sent: Wednesday, January 05, 2011 3:18 PM > To: Henry Lum; andrew.hutton@siemens-enterprise.com; > pkyzivat@cisco.com; siprec@ietf.org > Subject: RE: [siprec] Participant role parameter in Metadata model >=20 > The challenge I see is that in real-world applications of this > specification, UAC to UAS is not descriptive enough for real-world call > center supervisors and financial regulatory authorities to truly find > and recognize a call. As you note, in the 3PCC scenario noted below, 2 > recordings of essentially an identical conversation from an end-user > perspective. >=20 > Another scenario, which is a typical use case, is cradle-to-grave > recording scenarios. UAC to UAS conversations represent, in effect, in > a B2BUA environment individual conversation legs. However, in > cradle-to-grave scenarios, we would need a mechanism to relate all > related UAC to UAS calls into a single presentable call. If the > metadata model included a concept of diversion (transfer) or a "global > call ID" this could be accommodated. Forgive me if I'm mistaken, but I > did not see this accommodated in the requirements. >=20 > Otherwise we risk the specification being less functional than existing > solutions, reducing the motivation for adoption and compliance. >=20 > Best Regards, >=20 > Sid Rao >=20 > -----Original Message----- > From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com] > Sent: Wednesday, January 05, 2011 3:12 PM > To: Sid Rao; andrew.hutton@siemens-enterprise.com; pkyzivat@cisco.com; > siprec@ietf.org > Subject: RE: [siprec] Participant role parameter in Metadata model >=20 > I agree the wording for uac and uas may be a bit too technical or too > raw and it can be confusing to interpret what it really means. For > example, if a caller uses a 3pcc application to place a call to a > callee, the 3pcc app would place two SIP dialogs to the caller and > callee and join them together, and you will end up with two uas parties > which can be difficult to interpret the result. >=20 > Ideally I think it should be something like calling party or called > party. If the SRC understands how to interpret the party role then it > can record it in the metadata. >=20 > Henry >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Sid Rao > > Sent: Wednesday, January 05, 2011 8:36 AM > > To: andrew.hutton@siemens-enterprise.com; pkyzivat@cisco.com; > > siprec@ietf.org > > Subject: Re: [siprec] Participant role parameter in Metadata model > > > > Ideally, there would be additional data about the call (redirection, > > for example), with the ability to provide additional ancillary custom > > data. > > > > Sid Rao - Chief Technology Officer - CTI Group, Inc. - +1 (317) 262- > > 4677 > > > > ----- Original Message ----- > > From: siprec-bounces@ietf.org > > To: Paul Kyzivat ; siprec@ietf.org > > > > Sent: Wed Jan 05 05:55:27 2011 > > Subject: Re: [siprec] Participant role parameter in Metadata model > > > > > > I agree with Paul that this needs some thought. > > > > I suspect that the SRS does not need information about who is the uac > > or uas for a given SIP transaction but will want to know the role of > > each participant with regard to the session. For example who is the > > calling/called parties (i.e. who was the uac for the initial dialog > > creating INVITE). > > > > The SRS may also need information about who initiates any additional > > media streams during a session but I am not sure about this. > > > > The requirements are not much help as we only have REQ-12 which > states: > > > > "The mechanism MUST provide the SRS with metadata describing CSs that > > are being recorded, including the media being used and the identities > > of parties involved". > > > > Regards > > Andy > > > > > > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > Sent: 03 January 2011 15:57 > > To: siprec@ietf.org > > Subject: Re: [siprec] Participant role parameter in Metadata model > > > > > > > > On 1/3/2011 6:53 AM, Parthasarathi R (partr) wrote: > > > Hi all, > > > From the current metadata parameters, it is not possible for SRS > to >=20 > > > deduce whether the participant is acting as "uac" or "uas" for a > > given > > > transaction in CS but SRC is aware of this information in most of > the > > > scenarios. Participant role information in CS will be lost as RS is > > not > > > carry this information as part of metadata. IMO, it is better to > add >=20 > > > this information as participant role with value as "uac" or "uas" > or >=20 > > > "don't know" in the metadata. > > > This information helps to understand who initiated the dialog from > > SRS > > > perspective in case SRS has more configuration/metadata information > > > about the participant. Please let me know whether it is worth to > add >=20 > > > this information as part of participant metadata information. > > > Thanks > > > Partha > > > > Its at least going to take some thought to get this right. > > The metadata we have defined isn't really structured transactionally > > the same way sip is. Its more "declarative" than operational. > > > > So for instance, there might be a metadata change that adds an > > additional media stream. There may have been multiple sip > transactions >=20 > > take place to negotiate that new media stream. One specific > participant > > may have sent the first transaction that initiated an o/a negotiation > > that resulted in the new media stream. But its possible the the first > > offer of that stream came from a different participant. > > > > Now, perhaps there is some interest in recording all, or a summary, > of >=20 > > all the sip traffic on the CS as part of the metadata. But that is > > likely to be overkill. If not, then I think roles such as UAC and UAS > > need to be translated into something that makes sense in the > metadata. > > I'm not entirely sure what that would be - it varies for different > > pieces of the metadata. > > > > Thanks, > > Paul > > > > > _______________________________________________ > > > 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 > > > > > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit http://www.messagelabs.com/email > > > ______________________________________________________________________ > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec >=20 >=20 > ----------------------------------------------------------------------- > - > ------------------------------------------- > CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain > confidential and proprietary information of Alcatel-Lucent and/or its > affiliated entities. Access by the intended recipient only is > authorized. Any liability arising from any party acting, or refraining > from acting, on any information contained in this e-mail is hereby > excluded. If you are not the intended recipient, please notify the > sender immediately, destroy the original transmission and its > attachments and do not disclose the contents to any other person, use > it > for any purpose, or store or copy the information in any medium. > Copyright in this e-mail and any attachments belongs to Alcatel-Lucent > and/or its affiliated entities. >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From partr@cisco.com Wed Jan 5 22:21:16 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AA8A3A6E43 for ; Wed, 5 Jan 2011 22:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.094 X-Spam-Level: X-Spam-Status: No, score=-10.094 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMTIN3E3KphW for ; Wed, 5 Jan 2011 22:21:09 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 576E13A6E45 for ; Wed, 5 Jan 2011 22:21:09 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJLuJE1AaMHG/2dsb2JhbACkHnOmCpg6gnSCWASEZYlH X-IronPort-AV: E=Sophos;i="4.60,282,1291593600"; d="scan'208";a="396592882" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-1.cisco.com with ESMTP; 06 Jan 2011 06:23:05 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p066MaXY012104; Thu, 6 Jan 2011 06:23:02 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Jan 2011 11:52:59 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Jan 2011 11:52:58 +0530 Message-ID: In-Reply-To: <059AF07365DC474393A19A3AF187DF740688C2F6@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Participant role parameter in Metadata model Thread-Index: AcurXtEzhjm56jp0QrirUNESYYJ+cgBZcNTwAAY77nsADUNOMAAAlotwAALAFzAAERgKoA== References: <101C6067BEC68246B0C3F6843BCCC1E309B382B996@MCHP058A.global-ad.net><059AF07365DC474393A19A3AF187DF740688C27E@NAHALD.us.int.genesyslab.com> <059AF07365DC474393A19A3AF187DF740688C2F6@NAHALD.us.int.genesyslab.com> From: "Parthasarathi R (partr)" To: "Henry Lum" , "Sid Rao" , , "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 06 Jan 2011 06:22:59.0089 (UTC) FILETIME=[29E03810:01CBAD6A] Subject: Re: [siprec] Participant role parameter in Metadata model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 06:21:16 -0000 The main notion for starting this mail thread is to 1) Identify the initiator of the call (caller, callee) 2) To track which Participant puts on hold/resume or other media changes I proposed "uac" & "uas" as they are well accepted in SIP world (RFC 3261). It is possible to SRS to deduce the different meaning based on the other attributes and configuration. I completely agree that it is too generic term for call-centre applications.=20 The individual attributes like "caller" and "callee" may mislead in few B2BUA based transfer scenarios. The example is as follows: 1) A calls B ---> A - Caller, B - Callee 2) A put B on hold 3) A calls c ---> A - Caller, B - Callee 4) A transfer C to B ----> B - Callee, C - Callee Initial proposal of "Initiator" and "direction" are removed from the metadata model. I'm fine in case we come up the most acceptable attribute specific for recording. Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum Sent: Thursday, January 06, 2011 3:06 AM To: Sid Rao; andrew.hutton@siemens-enterprise.com; Paul Kyzivat (pkyzivat); siprec@ietf.org Subject: Re: [siprec] Participant role parameter in Metadata model For cradle-to-grave scenarios, the SRC may choose to use a CS group to represent a series of call transfers to different parties in the call, where each transfer may be considered a separate CS. There is a use case outlined in the metadata draft to describe such scenario (use case 3). Regards, Henry > -----Original Message----- > From: Sid Rao [mailto:srao@ctigroup.com] > Sent: Wednesday, January 05, 2011 3:18 PM > To: Henry Lum; andrew.hutton@siemens-enterprise.com; > pkyzivat@cisco.com; siprec@ietf.org > Subject: RE: [siprec] Participant role parameter in Metadata model >=20 > The challenge I see is that in real-world applications of this=20 > specification, UAC to UAS is not descriptive enough for real-world call > center supervisors and financial regulatory authorities to truly find=20 > and recognize a call. As you note, in the 3PCC scenario noted below, 2 > recordings of essentially an identical conversation from an end-user=20 > perspective. >=20 > Another scenario, which is a typical use case, is cradle-to-grave=20 > recording scenarios. UAC to UAS conversations represent, in effect, in > a B2BUA environment individual conversation legs. However, in=20 > cradle-to-grave scenarios, we would need a mechanism to relate all=20 > related UAC to UAS calls into a single presentable call. If the=20 > metadata model included a concept of diversion (transfer) or a "global > call ID" this could be accommodated. Forgive me if I'm mistaken, but I > did not see this accommodated in the requirements. >=20 > Otherwise we risk the specification being less functional than existing > solutions, reducing the motivation for adoption and compliance. >=20 > Best Regards, >=20 > Sid Rao >=20 > -----Original Message----- > From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com] > Sent: Wednesday, January 05, 2011 3:12 PM > To: Sid Rao; andrew.hutton@siemens-enterprise.com; pkyzivat@cisco.com; > siprec@ietf.org > Subject: RE: [siprec] Participant role parameter in Metadata model >=20 > I agree the wording for uac and uas may be a bit too technical or too=20 > raw and it can be confusing to interpret what it really means. For=20 > example, if a caller uses a 3pcc application to place a call to a=20 > callee, the 3pcc app would place two SIP dialogs to the caller and=20 > callee and join them together, and you will end up with two uas parties > which can be difficult to interpret the result. >=20 > Ideally I think it should be something like calling party or called=20 > party. If the SRC understands how to interpret the party role then it=20 > can record it in the metadata. >=20 > Henry >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > > Behalf Of Sid Rao > > Sent: Wednesday, January 05, 2011 8:36 AM > > To: andrew.hutton@siemens-enterprise.com; pkyzivat@cisco.com;=20 > > siprec@ietf.org > > Subject: Re: [siprec] Participant role parameter in Metadata model > > > > Ideally, there would be additional data about the call (redirection, > > for example), with the ability to provide additional ancillary custom > > data. > > > > Sid Rao - Chief Technology Officer - CTI Group, Inc. - +1 (317) 262- > > 4677 > > > > ----- Original Message ----- > > From: siprec-bounces@ietf.org > > To: Paul Kyzivat ; siprec@ietf.org=20 > > > > Sent: Wed Jan 05 05:55:27 2011 > > Subject: Re: [siprec] Participant role parameter in Metadata model > > > > > > I agree with Paul that this needs some thought. > > > > I suspect that the SRS does not need information about who is the uac > > or uas for a given SIP transaction but will want to know the role of > > each participant with regard to the session. For example who is the=20 > > calling/called parties (i.e. who was the uac for the initial dialog=20 > > creating INVITE). > > > > The SRS may also need information about who initiates any additional > > media streams during a session but I am not sure about this. > > > > The requirements are not much help as we only have REQ-12 which > states: > > > > "The mechanism MUST provide the SRS with metadata describing CSs that > > are being recorded, including the media being used and the identities > > of parties involved". > > > > Regards > > Andy > > > > > > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > > Behalf Of Paul Kyzivat > > Sent: 03 January 2011 15:57 > > To: siprec@ietf.org > > Subject: Re: [siprec] Participant role parameter in Metadata model > > > > > > > > On 1/3/2011 6:53 AM, Parthasarathi R (partr) wrote: > > > Hi all, > > > From the current metadata parameters, it is not possible for SRS > to >=20 > > > deduce whether the participant is acting as "uac" or "uas" for a > > given > > > transaction in CS but SRC is aware of this information in most of > the > > > scenarios. Participant role information in CS will be lost as RS is > > not > > > carry this information as part of metadata. IMO, it is better to > add >=20 > > > this information as participant role with value as "uac" or "uas" > or >=20 > > > "don't know" in the metadata. > > > This information helps to understand who initiated the dialog from > > SRS > > > perspective in case SRS has more configuration/metadata information > > > about the participant. Please let me know whether it is worth to > add >=20 > > > this information as part of participant metadata information. > > > Thanks > > > Partha > > > > Its at least going to take some thought to get this right. > > The metadata we have defined isn't really structured transactionally > > the same way sip is. Its more "declarative" than operational. > > > > So for instance, there might be a metadata change that adds an=20 > > additional media stream. There may have been multiple sip > transactions >=20 > > take place to negotiate that new media stream. One specific > participant > > may have sent the first transaction that initiated an o/a negotiation > > that resulted in the new media stream. But its possible the the first > > offer of that stream came from a different participant. > > > > Now, perhaps there is some interest in recording all, or a summary, > of >=20 > > all the sip traffic on the CS as part of the metadata. But that is=20 > > likely to be overkill. If not, then I think roles such as UAC and UAS > > need to be translated into something that makes sense in the > metadata. > > I'm not entirely sure what that would be - it varies for different=20 > > pieces of the metadata. > > > > Thanks, > > Paul > > > > > _______________________________________________ > > > 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 > > > > > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit http://www.messagelabs.com/email > > > ______________________________________________________________________ > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec >=20 >=20 > ----------------------------------------------------------------------- > - > ------------------------------------------- > CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain > confidential and proprietary information of Alcatel-Lucent and/or its=20 > affiliated entities. Access by the intended recipient only is=20 > authorized. Any liability arising from any party acting, or refraining > from acting, on any information contained in this e-mail is hereby=20 > excluded. If you are not the intended recipient, please notify the=20 > sender immediately, destroy the original transmission and its=20 > attachments and do not disclose the contents to any other person, use=20 > it for any purpose, or store or copy the information in any medium. > Copyright in this e-mail and any attachments belongs to Alcatel-Lucent > and/or its affiliated entities. >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email=20 > ______________________________________________________________________ =09 ------------------------------------------------------------------------ ------------------------------------------- CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities. =09 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Thu Jan 6 02:12:25 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27CE93A6D14 for ; Thu, 6 Jan 2011 02:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPDEVEvWkksf for ; Thu, 6 Jan 2011 02:12:24 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 25C843A6CC8 for ; Thu, 6 Jan 2011 02:12:23 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2912382; Thu, 6 Jan 2011 11:14:29 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 706AB23F0278; Thu, 6 Jan 2011 11:14:29 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 6 Jan 2011 11:14:29 +0100 From: "Elwell, John" To: "Parthasarathi R (partr)" , Henry Lum , Sid Rao , "Hutton, Andrew" , "Paul Kyzivat (pkyzivat)" , "siprec@ietf.org" Date: Thu, 6 Jan 2011 11:14:28 +0100 Thread-Topic: [siprec] Participant role parameter in Metadata model Thread-Index: AcurXtEzhjm56jp0QrirUNESYYJ+cgBZcNTwAAY77nsADUNOMAAAlotwAALAFzAAERgKoAAJG3Ug Message-ID: References: <101C6067BEC68246B0C3F6843BCCC1E309B382B996@MCHP058A.global-ad.net><059AF07365DC474393A19A3AF187DF740688C27E@NAHALD.us.int.genesyslab.com> <059AF07365DC474393A19A3AF187DF740688C2F6@NAHALD.us.int.genesyslab.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Participant role parameter in Metadata model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 10:12:25 -0000 I think most points have already been made by others, but my view is as fol= lows (some of this was also discussed some time ago in other threads). 1. The UAC and UAS terms are transaction-oriented - during the lifetime of = a CS there can be many transactions, some in one direction and some in the = other direction. 2. We could limit it to the dialog-forming transactions - whether the SRC i= s associated with the UAC or UAS of that initial transaction. I am not sure= why this information would be of any use to the SRS in many cases. For exa= mple, if calls are established by 3PCC, the UA with which the SRC is associ= ated might always be the UAS of the dialog-forming transaction, so no meani= ngful information will be delivered to the SRS. 3. Where the SRC is associated with a B2BUA, the B2BUA would act as both SR= C and SRS during dialog formation, i.e., the SRS or one dialog and the SRC = of the other dialog, both dialogs being part of the same CS. Perhaps we hav= e to consider the B2BUA as acting on behalf of one party. 4. There are also issues where the SRC is associated with a conference focu= s. 5. Information that might really benefit the SRS would be direction of CS e= stablishment, i.e., whether the SRC is acting on behalf of the calling or c= alled party. However, particularly in 3PCC situations, this might not be kn= own. Also this might not be meaningful in conference situations. I would be curious what existing implementations use and how this works in = 3PCC, B2BUA and conference situations. John (as individual) From rmohanr@cisco.com Fri Jan 7 05:24:25 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A5973A68C2 for ; Fri, 7 Jan 2011 05:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.191 X-Spam-Level: X-Spam-Status: No, score=-10.191 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBuC7x2+Hf2b for ; Fri, 7 Jan 2011 05:24:24 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 5B12E3A683B for ; Fri, 7 Jan 2011 05:24:24 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFAPuiJk1AaMHG/2dsb2JhbACCKaF9c6QLmDWFTASEZYlI Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 07 Jan 2011 13:26:30 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p07DPuip027981; Fri, 7 Jan 2011 13:26:29 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Jan 2011 18:56:24 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBAE6E.7AC0B1AD" Date: Fri, 7 Jan 2011 18:56:23 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD04E1FC6E@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD04CCC1F7@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] SIPREC Metadata Model: Soliciting use cases for CSs tobeconcurrently associated (different views) with multiple CS-Groups Thread-Index: AcuhD3COLexGMLuuRnS0V5zAt3X03gKGVMSgANFkyVA= References: <35BCE99A477D6A4986FB2216D8CF2CFD04CCB7EE@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD04CCC1F7@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: , "De Villiers de Wet" X-OriginalArrivalTime: 07 Jan 2011 13:26:24.0169 (UTC) FILETIME=[7AE58990:01CBAE6E] Subject: Re: [siprec] SIPREC Metadata Model: Soliciting use cases for CSs tobeconcurrently associated (different views) with multiple CS-Groups X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 13:24:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBAE6E.7AC0B1AD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have not heard any use cases on CSs to be concurrently associated with multiple CS-groups. I will go ahead and remove this open item in the version -03 of draft =20 Ram =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) Sent: Monday, January 03, 2011 3:03 PM To: siprec@ietf.org; De Villiers de Wet Subject: Re: [siprec] SIPREC Metadata Model: Soliciting use cases for CSs tobeconcurrently associated (different views) with multiple CS-Groups =20 I have not heard any use cases for CSs to be concurrently associated with multiple CS-Groups. Please let me have the use cases if any before Jan 5th 2011. Otherwise I will close this open item of metadata and retain the association as described in draft-ram-siprec-metadata-02. =20 Regards, Ram =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) Sent: Tuesday, December 21, 2010 6:33 PM To: siprec@ietf.org; De Villiers de Wet Subject: [siprec] SIPREC Metadata Model: Soliciting use cases for CSs to beconcurrently associated (different views) with multiple CS-Groups =20 Hi All, =20 During the SIPREC IETF virtual interim meeting on Dec 16th 2010, it was unclear on use cases for a Communication Session (CS) to be associated with multiple CS-Groups concurrently.=20 =20 Can someone suggest some use cases by which we can evaluate if this association is needed ? =20 In some of the earlier discussions [ with De Villiers de Wet] it was seen that we may need different groupings (from the perspective of customer, from the perspective of Agent or supervisor). Storing these different views(groupings) may be useful at SRS as there may be applications that may query for one view(a customer's view or agents view or supervisors view).=20 However it was later agreed that these views can be derived by SRS by using the existing SIPREC metadata model ( from participants) even without having a Communication Session (CS) to be associated with multiple CS-Groups concurrently. =20 If there are no compelling use cases, I will close this open item and have the association as it is in the current model(draft-ram-siprec-metadata-02) =20 Regards, Ram =20 =20 =20 =20 ------_=_NextPart_001_01CBAE6E.7AC0B1AD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have not heard any use cases on CSs to be = concurrently associated with multiple CS-groups.

I will go ahead and = remove this open item in the version -03 of = draft

 

Ram

 

From:= = siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Ram Mohan R (rmohanr)
Sent: Monday, January 03, 2011 3:03 = PM
To: siprec@ietf.org; De Villiers de Wet
Subject: = Re: [siprec] SIPREC Metadata Model: Soliciting use cases for CSs = tobeconcurrently associated (different views) with multiple = CS-Groups

 

I have not heard any use cases for CSs to be = concurrently associated with multiple CS-Groups.  Please let me = have the use cases  if any before Jan 5th = 2011.

Otherwise I will close this open item of = metadata and retain the association as described in = draft-ram-siprec-metadata-02.

 

Regards,

Ram

 

From:= = siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Ram Mohan R (rmohanr)
Sent: Tuesday, December 21, 2010 = 6:33 PM
To: siprec@ietf.org; De Villiers de = Wet
Subject: [siprec] SIPREC Metadata Model: Soliciting use = cases for CSs to beconcurrently associated (different views) with = multiple CS-Groups

 

Hi = All,

 

During the SIPREC IETF virtual interim meeting on Dec = 16th 2010, it was unclear on use cases for  a = Communication Session (CS) to be associated with multiple CS-Groups = concurrently.

 

Can someone = suggest some use cases by which we can evaluate if this association is = needed ?

 

In some of the earlier discussions [  with De = Villiers de Wet] it was seen that we may need different groupings (from = the perspective of customer, from the perspective of Agent or = supervisor). Storing these different views(groupings) may be useful at = SRS as there may be applications that  may query for one view(a = customer's view or agents view or  supervisors view). =

However it was later agreed that = these views can be derived by SRS by using the existing  SIPREC = metadata model  ( from participants) even without having a = Communication Session (CS) to be associated with multiple CS-Groups = concurrently.

 

If there are no compelling use cases, I will close = this open item and have the association as it is in the current = model(draft-ram-siprec-metadata-02)

 

Regards,

Ram

 

 

 

 

------_=_NextPart_001_01CBAE6E.7AC0B1AD-- From john.elwell@siemens-enterprise.com Wed Jan 12 04:09:57 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B3C728C100 for ; Wed, 12 Jan 2011 04:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ACB-ecQ2FFb for ; Wed, 12 Jan 2011 04:09:56 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 8AAB128C0E9 for ; Wed, 12 Jan 2011 04:09:56 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2975544 for siprec@ietf.org; Wed, 12 Jan 2011 13:12:14 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id D603B1EB82AB for ; Wed, 12 Jan 2011 13:12:14 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 12 Jan 2011 13:12:14 +0100 From: "Elwell, John" To: "siprec@ietf.org" Date: Wed, 12 Jan 2011 13:12:13 +0100 Thread-Topic: Agenda requests plus reminder Thread-Index: AcuyUfJnU/vECby9TGaM0uRbXItGhA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Agenda requests plus reminder X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 12:09:57 -0000 Please let me have your agenda requests for the dual interim on 25th/26th. Also, a reminder that WGLC on siprec-req is into its second week and I have= not seen any responses yet. Even if you are happy with it as is, a note to= the list would be helpful. John From partr@cisco.com Wed Jan 12 16:26:42 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5EC33A67B4 for ; Wed, 12 Jan 2011 16:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.409 X-Spam-Level: X-Spam-Status: No, score=-9.409 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QklZWRjPybh7 for ; Wed, 12 Jan 2011 16:26:40 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5F17C3A67AE for ; Wed, 12 Jan 2011 16:26:39 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEEAKLVLU2Q/khLgWdsb2JhbACja1kVAQEWIiSjIJhxhUwEhGaJUA Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 13 Jan 2011 00:28:59 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p0D0RRCC023734; Thu, 13 Jan 2011 00:28:58 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Jan 2011 05:58:39 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBB2B8.C2DE6BBF" Date: Thu, 13 Jan 2011 05:58:12 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Participant role parameter in Metadata model Thread-Index: AcurXtEzhjm56jp0QrirUNESYYJ+cgBZcNTwAAY77nsADUNOMAAAlotwAALAFzAAERgKoAAJG3UgAUsF1lg= References: <101C6067BEC68246B0C3F6843BCCC1E309B382B996@MCHP058A.global-ad.net><059AF07365DC474393A19A3AF187DF740688C27E@NAHALD.us.int.genesyslab.com><059AF07365DC474393A19A3AF187DF740688C2F6@NAHALD.us.int.genesyslab.com> From: "Parthasarathi R (partr)" To: "Elwell, John" , "Henry Lum" , "Sid Rao" , "Hutton, Andrew" , "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 13 Jan 2011 00:28:39.0403 (UTC) FILETIME=[D301D3B0:01CBB2B8] Subject: Re: [siprec] Participant role parameter in Metadata model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 00:26:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBB2B8.C2DE6BBF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable John, =20 Sorry for the delay response. Please read inline. =20 Thanks Partha ________________________________ From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] Sent: Thu 1/6/2011 3:44 PM To: Parthasarathi R (partr); Henry Lum; Sid Rao; Hutton, Andrew; Paul = Kyzivat (pkyzivat); siprec@ietf.org Subject: RE: [siprec] Participant role parameter in Metadata model I think most points have already been made by others, but my view is as = follows (some of this was also discussed some time ago in other = threads). 1. The UAC and UAS terms are transaction-oriented - during the lifetime = of a CS there can be many transactions, some in one direction and some = in the other direction. Agreed 2. We could limit it to the dialog-forming transactions - It depends upon the level of analysis and service provided by = SRS. For example: Example 1: 1) Audio dialog is established between A and B and A is the caller. 2) B send new offer with Video and the dialog is escalated to video = between A and B after A answer >From Recording, it may be required to understand who make the dialog as = video apart who initiated the dialog Example2: Agent performance shall be measured by the amount of time the customer = is in the call hold by Agent but hold put by customer should not be = considered for the performance.=20 IOW, The initiator of the new offer within dialog may be of interest for = few services. Please let me know your opinion here. UAC and UAS may be = very crude terms, but we need to work for better terminology which is = specific to recording whether the SRC is associated with the UAC or UAS of that initial = transaction. I am not sure why this information would be of any use to = the SRS in many cases.=20 The information is useful to derive caller/callee in case = caller/callee information is not passed across For example, if calls are established by 3PCC, the UA with which the SRC = is associated might always be the UAS of the dialog-forming transaction, = so no meaningful information will be delivered to the SRS. Agreed. Caller/Callee is not applicable for all SIP devices but = it is critical for few SIP devices (Call Centre solution). This = information shall be optional parameter rather than mandatory 3. Where the SRC is associated with a B2BUA, the B2BUA would act as both = SRC and SRS during dialog formation, I guess that you are intended to say B2BUA acts as both UAC and = UAS. i.e., the SRS or one dialog and the SRC of the other dialog, both = dialogs being part of the same CS. Perhaps we have to consider the B2BUA = as acting on behalf of one party. B2BUA has convert UAC or UAS information appropriately as it is = middle box in the dialog 4. There are also issues where the SRC is associated with a conference = focus. Participant role information may be irrelevant. As I mentioned, = this information is not generic enough. 5. Information that might really benefit the SRS would be direction of = CS establishment, i.e., whether the SRC is acting on behalf of the = calling or called party.=20 For -03 metadata draft, we will keep initiator attribute in CS = However, particularly in 3PCC situations, this might not be known. Also = this might not be meaningful in conference situations. I would be curious what existing implementations use and how this works = in 3PCC, B2BUA and conference situations. From the discussion in SIPREC, my understanding is that the = participant role information is required in most of the call centre = solution to distinguish whether Agent initiated the call or customer = initiated the call John (as individual) ------_=_NextPart_001_01CBB2B8.C2DE6BBF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [siprec] Participant role parameter in = Metadata model=0A= =0A= =0A= =0A=
=0A=
=0A=
=0A=
=0A=
John,
=0A=
 
=0A=
Sorry for the delay response. = Please read inline.
=0A=
 
=0A=
Thanks
=0A=
Partha
=0A=

=0A=
=0A= From: Elwell, John = [mailto:john.elwell@siemens-enterprise.com]
Sent: Thu 1/6/2011 = 3:44 PM
To: Parthasarathi R (partr); Henry Lum; Sid Rao; = Hutton, Andrew; Paul Kyzivat (pkyzivat); = siprec@ietf.org
Subject: RE: [siprec] Participant role = parameter in Metadata model

=0A=
=0A=

I think most points have already been made by others, = but my view is as follows (some of this was also discussed some time ago = in other threads).

1. The UAC and UAS terms are = transaction-oriented - during the lifetime of a CS there can be many = transactions, some in one direction and some in the other = direction.
<Partha> Agreed </Partha>
2. We could limit = it to the dialog-forming transactions -

=0A=

<Partha> It depends upon the level of analysis = and service provided by SRS. For example:

=0A=

Example 1:

=0A=

1) Audio dialog is established between A and B and A = is the caller.

=0A=

2) B send new offer with Video and the dialog is = escalated to video between A and B after A answer

=0A=

From Recording, it may be required to understand who = make the dialog as video apart who initiated the dialog

=0A=

Example2:

=0A=

Agent performance shall be measured = by the amount of time the customer is in the call hold by = Agent but hold put by customer should not be considered for = the performance.

=0A=

IOW, The initiator of the new offer within dialog may = be of interest for few services. Please let me know your = opinion here. UAC and UAS  may be = very crude terms, but we need to work for better terminology which is = specific to recording </Partha>

=0A=

 whether the SRC is associated with the UAC or = UAS of that initial transaction. I am not sure why this information = would be of any use to the SRS in many cases.

=0A=

<Partha> The information is useful = to derive caller/callee in case caller/callee information is = not passed across </Partha>

=0A=

For example, if calls are established by 3PCC, the UA = with which the SRC is associated might always be the UAS of the = dialog-forming transaction, so no meaningful information will be = delivered to the SRS.

=0A=

<Partha> Agreed. Caller/Callee is not applicable = for all SIP devices but it is critical for few SIP devices (Call Centre = solution). This information shall be optional parameter rather than = mandatory </Partha>

3. Where the SRC is associated = with a B2BUA, the B2BUA would act as both SRC and SRS during dialog = formation,

=0A=

<Partha> I guess that you are intended to say = B2BUA acts as both UAC and UAS. </Partha>

=0A=

 i.e., the SRS or one dialog and the SRC of the = other dialog, both dialogs being part of the same CS. Perhaps we have to = consider the B2BUA as acting on behalf of one party.
<Partha> = B2BUA has convert UAC or UAS information appropriately as it is middle = box in the dialog </Partha>
4. There are also issues where the = SRC is associated with a conference focus.

=0A=

<Partha> Participant role information = may be irrelevant. As I mentioned, this information is not generic = enough. </Partha>

5. Information that might really benefit = the SRS would be direction of CS establishment, i.e., whether the SRC is = acting on behalf of the calling or called party.

=0A=

<Partha> For = -03 metadata draft, we will keep initiator attribute in CS = </Partha>

=0A=

However, particularly in 3PCC situations, this might = not be known. Also this might not be meaningful in conference = situations.

I would be curious what existing implementations use = and how this works in 3PCC, B2BUA and conference situations.

=0A=

<Partha> From the discussion in SIPREC, my = understanding is that the participant role information is required in = most of the call centre solution to distinguish whether Agent initiated = the call or customer initiated the call </Partha>

John (as = individual)


------_=_NextPart_001_01CBB2B8.C2DE6BBF-- From john.elwell@siemens-enterprise.com Wed Jan 12 23:30:06 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1636D3A6998 for ; Wed, 12 Jan 2011 23:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWGjFk+SSudz for ; Wed, 12 Jan 2011 23:30:03 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 5FC673A6A99 for ; Wed, 12 Jan 2011 23:30:02 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2987114; Thu, 13 Jan 2011 08:32:22 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id A29F423F0278; Thu, 13 Jan 2011 08:32:22 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 13 Jan 2011 08:32:22 +0100 From: "Elwell, John" To: "Parthasarathi R (partr)" , Henry Lum , Sid Rao , "Hutton, Andrew" , "Paul Kyzivat (pkyzivat)" , "siprec@ietf.org" Date: Thu, 13 Jan 2011 08:32:20 +0100 Thread-Topic: [siprec] Participant role parameter in Metadata model Thread-Index: AcurXtEzhjm56jp0QrirUNESYYJ+cgBZcNTwAAY77nsADUNOMAAAlotwAALAFzAAERgKoAAJG3UgAUsF1lgAD3QoEA== Message-ID: References: <101C6067BEC68246B0C3F6843BCCC1E309B382B996@MCHP058A.global-ad.net><059AF07365DC474393A19A3AF187DF740688C27E@NAHALD.us.int.genesyslab.com><059AF07365DC474393A19A3AF187DF740688C2F6@NAHALD.us.int.genesyslab.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Participant role parameter in Metadata model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 07:30:06 -0000 =20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 > Sent: 13 January 2011 00:28 > To: Elwell, John; Henry Lum; Sid Rao; Hutton, Andrew; Paul=20 > Kyzivat (pkyzivat); siprec@ietf.org > Subject: RE: [siprec] Participant role parameter in Metadata model >=20 > John, > =20 > Sorry for the delay response. Please read inline. > =20 > Thanks > Partha >=20 > ________________________________ >=20 > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thu 1/6/2011 3:44 PM > To: Parthasarathi R (partr); Henry Lum; Sid Rao; Hutton,=20 > Andrew; Paul Kyzivat (pkyzivat); siprec@ietf.org > Subject: RE: [siprec] Participant role parameter in Metadata model >=20 >=20 >=20 > I think most points have already been made by others, but my=20 > view is as follows (some of this was also discussed some time=20 > ago in other threads). >=20 > 1. The UAC and UAS terms are transaction-oriented - during=20 > the lifetime of a CS there can be many transactions, some in=20 > one direction and some in the other direction. > Agreed > 2. We could limit it to the dialog-forming transactions - >=20 > It depends upon the level of analysis and service=20 > provided by SRS. For example: >=20 > Example 1: >=20 > 1) Audio dialog is established between A and B and A is the caller. >=20 > 2) B send new offer with Video and the dialog is escalated to=20 > video between A and B after A answer >=20 > From Recording, it may be required to understand who make the=20 > dialog as video apart who initiated the dialog >=20 > Example2: >=20 > Agent performance shall be measured by the amount of time the=20 > customer is in the call hold by Agent but hold put by=20 > customer should not be considered for the performance.=20 >=20 > IOW, The initiator of the new offer within dialog may be of=20 > interest for few services. Please let me know your opinion=20 > here. UAC and UAS may be very crude terms, but we need to=20 > work for better terminology which is specific to recording >=20 > whether the SRC is associated with the UAC or UAS of that=20 > initial transaction. I am not sure why this information would=20 > be of any use to the SRS in many cases.=20 >=20 > The information is useful to derive caller/callee in=20 > case caller/callee information is not passed across >=20 > For example, if calls are established by 3PCC, the UA with=20 > which the SRC is associated might always be the UAS of the=20 > dialog-forming transaction, so no meaningful information will=20 > be delivered to the SRS. >=20 > Agreed. Caller/Callee is not applicable for all SIP=20 > devices but it is critical for few SIP devices (Call Centre=20 > solution). This information shall be optional parameter=20 > rather than mandatory [JRE] But even a call centre solution could be implemented by 3PCC, so the = direction of call establishment would not necessarily be available to the S= RC. The direction of the initial offer might sometimes give a clue, but the= re are different approaches that can be taken for 3PCC. so I am not sure th= is would be a lot more reliable than the direction of the INVITE request. >=20 > 3. Where the SRC is associated with a B2BUA, the B2BUA would=20 > act as both SRC and SRS during dialog formation, >=20 > I guess that you are intended to say B2BUA acts as=20 > both UAC and UAS. [JRE] Yes, sorry for the confusion. I meant, of course, that the B2BUA acts= as both UAC and UAS. >=20 > i.e., the SRS or one dialog and the SRC of the other dialog,=20 > both dialogs being part of the same CS. Perhaps we have to=20 > consider the B2BUA as acting on behalf of one party. > B2BUA has convert UAC or UAS information=20 > appropriately as it is middle box in the dialog > 4. There are also issues where the SRC is associated with a=20 > conference focus. >=20 > Participant role information may be irrelevant. As I=20 > mentioned, this information is not generic enough. >=20 > 5. Information that might really benefit the SRS would be=20 > direction of CS establishment, i.e., whether the SRC is=20 > acting on behalf of the calling or called party.=20 >=20 > For -03 metadata draft, we will keep initiator=20 > attribute in CS >=20 > However, particularly in 3PCC situations, this might not be=20 > known. Also this might not be meaningful in conference situations. >=20 > I would be curious what existing implementations use and how=20 > this works in 3PCC, B2BUA and conference situations. >=20 > From the discussion in SIPREC, my understanding is=20 > that the participant role information is required in most of=20 > the call centre solution to distinguish whether Agent=20 > initiated the call or customer initiated the call [JRE] Yes, I understand people have said it is required, but I am still cur= ious how they solve it today, particularly for 3PCC and conference situatio= ns. John (as individual) From pkyzivat@cisco.com Thu Jan 13 06:12:44 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3486B3A6B90 for ; Thu, 13 Jan 2011 06:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.482 X-Spam-Level: X-Spam-Status: No, score=-110.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 397fvPzsbpVZ for ; Thu, 13 Jan 2011 06:12:43 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E55043A6B8D for ; Thu, 13 Jan 2011 06:12:42 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 13 Jan 2011 14:15:05 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0DEF59x008092; Thu, 13 Jan 2011 14:15:05 GMT Message-ID: <4D2F08E9.2010804@cisco.com> Date: Thu, 13 Jan 2011 09:15:05 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Elwell, John" References: <101C6067BEC68246B0C3F6843BCCC1E309B382B996@MCHP058A.global-ad.net><059AF07365DC474393A19A3AF187DF740688C27E@NAHALD.us.int.genesyslab.com><059AF07365DC474393A19A3AF187DF740688C2F6@NAHALD.us.int.genesyslab.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" , Henry Lum Subject: Re: [siprec] Participant role parameter in Metadata model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 14:12:44 -0000 I think the best we can do for call (and media) origination is to provide a way for the SRC to specify this when it knows, while recognizing that it may not always be known. Thanks, Paul On 1/13/2011 2:32 AM, Elwell, John wrote: > > >> -----Original Message----- >> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >> Sent: 13 January 2011 00:28 >> To: Elwell, John; Henry Lum; Sid Rao; Hutton, Andrew; Paul >> Kyzivat (pkyzivat); siprec@ietf.org >> Subject: RE: [siprec] Participant role parameter in Metadata model >> >> John, >> >> Sorry for the delay response. Please read inline. >> >> Thanks >> Partha >> >> ________________________________ >> >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> Sent: Thu 1/6/2011 3:44 PM >> To: Parthasarathi R (partr); Henry Lum; Sid Rao; Hutton, >> Andrew; Paul Kyzivat (pkyzivat); siprec@ietf.org >> Subject: RE: [siprec] Participant role parameter in Metadata model >> >> >> >> I think most points have already been made by others, but my >> view is as follows (some of this was also discussed some time >> ago in other threads). >> >> 1. The UAC and UAS terms are transaction-oriented - during >> the lifetime of a CS there can be many transactions, some in >> one direction and some in the other direction. >> Agreed >> 2. We could limit it to the dialog-forming transactions - >> >> It depends upon the level of analysis and service >> provided by SRS. For example: >> >> Example 1: >> >> 1) Audio dialog is established between A and B and A is the caller. >> >> 2) B send new offer with Video and the dialog is escalated to >> video between A and B after A answer >> >> From Recording, it may be required to understand who make the >> dialog as video apart who initiated the dialog >> >> Example2: >> >> Agent performance shall be measured by the amount of time the >> customer is in the call hold by Agent but hold put by >> customer should not be considered for the performance. >> >> IOW, The initiator of the new offer within dialog may be of >> interest for few services. Please let me know your opinion >> here. UAC and UAS may be very crude terms, but we need to >> work for better terminology which is specific to recording >> >> whether the SRC is associated with the UAC or UAS of that >> initial transaction. I am not sure why this information would >> be of any use to the SRS in many cases. >> >> The information is useful to derive caller/callee in >> case caller/callee information is not passed across >> >> For example, if calls are established by 3PCC, the UA with >> which the SRC is associated might always be the UAS of the >> dialog-forming transaction, so no meaningful information will >> be delivered to the SRS. >> >> Agreed. Caller/Callee is not applicable for all SIP >> devices but it is critical for few SIP devices (Call Centre >> solution). This information shall be optional parameter >> rather than mandatory > [JRE] But even a call centre solution could be implemented by 3PCC, so the direction of call establishment would not necessarily be available to the SRC. The direction of the initial offer might sometimes give a clue, but there are different approaches that can be taken for 3PCC. so I am not sure this would be a lot more reliable than the direction of the INVITE request. > > >> >> 3. Where the SRC is associated with a B2BUA, the B2BUA would >> act as both SRC and SRS during dialog formation, >> >> I guess that you are intended to say B2BUA acts as >> both UAC and UAS. > [JRE] Yes, sorry for the confusion. I meant, of course, that the B2BUA acts as both UAC and UAS. > >> >> i.e., the SRS or one dialog and the SRC of the other dialog, >> both dialogs being part of the same CS. Perhaps we have to >> consider the B2BUA as acting on behalf of one party. >> B2BUA has convert UAC or UAS information >> appropriately as it is middle box in the dialog >> 4. There are also issues where the SRC is associated with a >> conference focus. >> >> Participant role information may be irrelevant. As I >> mentioned, this information is not generic enough. >> >> 5. Information that might really benefit the SRS would be >> direction of CS establishment, i.e., whether the SRC is >> acting on behalf of the calling or called party. >> >> For -03 metadata draft, we will keep initiator >> attribute in CS >> >> However, particularly in 3PCC situations, this might not be >> known. Also this might not be meaningful in conference situations. >> >> I would be curious what existing implementations use and how >> this works in 3PCC, B2BUA and conference situations. >> >> From the discussion in SIPREC, my understanding is >> that the participant role information is required in most of >> the call centre solution to distinguish whether Agent >> initiated the call or customer initiated the call > [JRE] Yes, I understand people have said it is required, but I am still curious how they solve it today, particularly for 3PCC and conference situations. > > John (as individual) > From john.elwell@siemens-enterprise.com Mon Jan 17 00:15:57 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B55753A6EB4 for ; Mon, 17 Jan 2011 00:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fy9qWtDoQVo9 for ; Mon, 17 Jan 2011 00:15:56 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 3E3423A6EB3 for ; Mon, 17 Jan 2011 00:15:54 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3028329 for siprec@ietf.org; Mon, 17 Jan 2011 09:18:26 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 7151E1EB82B0 for ; Mon, 17 Jan 2011 09:18:26 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 17 Jan 2011 09:18:26 +0100 From: "Elwell, John" To: "siprec@ietf.org" Date: Mon, 17 Jan 2011 09:18:23 +0100 Thread-Topic: [siprec] Participant role parameter in Metadata model Thread-Index: AcuzLEqZlpJ/TDyfTC6g3tXizZuBIACGy/DgABPn2UAAIfwkIA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] FW: Participant role parameter in Metadata model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 08:15:57 -0000 Forwarded on behalf of Dave Smith. > -----Original Message----- > From: Dave Smith [mailto:Dave.Smith@genesyslab.com]=20 > Sent: 16 January 2011 16:08 > To: Elwell, John > Subject: FW: [siprec] Participant role parameter in Metadata model >=20 > Hi John, >=20 > Can you please send this email out to the "siprec@ietf.org" email > address for me.=20 > Our Genesys email server is failing to send emails out to that address > again (in the mean time I will try to get it fixed through our > HelpDesk). >=20 > Thanks, > Dave >=20 >=20 >=20 > -----Original Message----- > From: Dave Smith=20 > Sent: Saturday, January 15, 2011 10:43 PM > To: Paul Kyzivat; Elwell, John > Cc: siprec@ietf.org; Henry Lum > Subject: RE: [siprec] Participant role parameter in Metadata model >=20 > I agree with Paul's conclusion. =20 >=20 > One Contact Center application I am aware of provides a Call Type > attribute to describe the CS using values such as Inbound, Outbound, > Internal, or Consult. Although they are not always accurate=20 > (e.g., for > transfers, for Outbound scenarios using dialers/3PCC. Individual > deployments have ways to work around this by understanding their call > flows and finding other ways to identify Call Type (e.g., using or > creating a specific CS metadata for those types of calls). =20 >=20 >=20 > Regards, > Dave >=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Thursday, January 13, 2011 6:15 AM > To: Elwell, John > Cc: siprec@ietf.org; Henry Lum > Subject: Re: [siprec] Participant role parameter in Metadata model >=20 > I think the best we can do for call (and media) origination is to=20 > provide a way for the SRC to specify this when it knows, while=20 > recognizing that it may not always be known. >=20 > Thanks, > Paul >=20 > On 1/13/2011 2:32 AM, Elwell, John wrote: > > > > > >> -----Original Message----- > >> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > >> Sent: 13 January 2011 00:28 > >> To: Elwell, John; Henry Lum; Sid Rao; Hutton, Andrew; Paul > >> Kyzivat (pkyzivat); siprec@ietf.org > >> Subject: RE: [siprec] Participant role parameter in Metadata model > >> > >> John, > >> > >> Sorry for the delay response. Please read inline. > >> > >> Thanks > >> Partha > >> > >> ________________________________ > >> > >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >> Sent: Thu 1/6/2011 3:44 PM > >> To: Parthasarathi R (partr); Henry Lum; Sid Rao; Hutton, > >> Andrew; Paul Kyzivat (pkyzivat); siprec@ietf.org > >> Subject: RE: [siprec] Participant role parameter in Metadata model > >> > >> > >> > >> I think most points have already been made by others, but my > >> view is as follows (some of this was also discussed some time > >> ago in other threads). > >> > >> 1. The UAC and UAS terms are transaction-oriented - during > >> the lifetime of a CS there can be many transactions, some in > >> one direction and some in the other direction. > >> Agreed > >> 2. We could limit it to the dialog-forming transactions - > >> > >> It depends upon the level of analysis and service > >> provided by SRS. For example: > >> > >> Example 1: > >> > >> 1) Audio dialog is established between A and B and A is the caller. > >> > >> 2) B send new offer with Video and the dialog is escalated to > >> video between A and B after A answer > >> > >> From Recording, it may be required to understand who make the > >> dialog as video apart who initiated the dialog > >> > >> Example2: > >> > >> Agent performance shall be measured by the amount of time the > >> customer is in the call hold by Agent but hold put by > >> customer should not be considered for the performance. > >> > >> IOW, The initiator of the new offer within dialog may be of > >> interest for few services. Please let me know your opinion > >> here. UAC and UAS may be very crude terms, but we need to > >> work for better terminology which is specific to recording > >> > >> whether the SRC is associated with the UAC or UAS of that > >> initial transaction. I am not sure why this information would > >> be of any use to the SRS in many cases. > >> > >> The information is useful to derive caller/callee in > >> case caller/callee information is not passed across > >> > >> For example, if calls are established by 3PCC, the UA with > >> which the SRC is associated might always be the UAS of the > >> dialog-forming transaction, so no meaningful information will > >> be delivered to the SRS. > >> > >> Agreed. Caller/Callee is not applicable for all SIP > >> devices but it is critical for few SIP devices (Call Centre > >> solution). This information shall be optional parameter > >> rather than mandatory > > [JRE] But even a call centre solution could be implemented=20 > by 3PCC, so > the direction of call establishment would not necessarily be available > to the SRC. The direction of the initial offer might sometimes give a > clue, but there are different approaches that can be taken=20 > for 3PCC. so > I am not sure this would be a lot more reliable than the direction of > the INVITE request. > > > > > >> > >> 3. Where the SRC is associated with a B2BUA, the B2BUA would > >> act as both SRC and SRS during dialog formation, > >> > >> I guess that you are intended to say B2BUA acts as > >> both UAC and UAS. > > [JRE] Yes, sorry for the confusion. I meant, of course,=20 > that the B2BUA > acts as both UAC and UAS. > > > >> > >> i.e., the SRS or one dialog and the SRC of the other dialog, > >> both dialogs being part of the same CS. Perhaps we have to > >> consider the B2BUA as acting on behalf of one party. > >> B2BUA has convert UAC or UAS information > >> appropriately as it is middle box in the dialog > >> 4. There are also issues where the SRC is associated with a > >> conference focus. > >> > >> Participant role information may be irrelevant. As I > >> mentioned, this information is not generic enough. > >> > >> 5. Information that might really benefit the SRS would be > >> direction of CS establishment, i.e., whether the SRC is > >> acting on behalf of the calling or called party. > >> > >> For -03 metadata draft, we will keep initiator > >> attribute in CS > >> > >> However, particularly in 3PCC situations, this might not be > >> known. Also this might not be meaningful in conference situations. > >> > >> I would be curious what existing implementations use and how > >> this works in 3PCC, B2BUA and conference situations. > >> > >> From the discussion in SIPREC, my understanding is > >> that the participant role information is required in most of > >> the call centre solution to distinguish whether Agent > >> initiated the call or customer initiated the call > > [JRE] Yes, I understand people have said it is required, but I am > still curious how they solve it today, particularly for 3PCC and > conference situations. > > > > John (as individual) > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >=20 > =09 > -------------------------------------------------------------- > ---------- > ------------------------------------------- > CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain > confidential and proprietary information of Alcatel-Lucent and/or its > affiliated entities. Access by the intended recipient only is > authorized. Any liability arising from any party acting, or refraining > from acting, on any information contained in this e-mail is hereby > excluded. If you are not the intended recipient, please notify the > sender immediately, destroy the original transmission and its > attachments and do not disclose the contents to any other=20 > person, use it > for any purpose, or store or copy the information in any medium. > Copyright in this e-mail and any attachments belongs to Alcatel-Lucent > and/or its affiliated entities. > =09 >=20 > =09 > -------------------------------------------------------------- > ----------------------------------------------------- > CONFIDENTIALITY NOTICE: This e-mail and any files attached=20 > may contain confidential and proprietary information of=20 > Alcatel-Lucent and/or its affiliated entities. Access by the=20 > intended recipient only is authorized. Any liability arising=20 > from any party acting, or refraining from acting, on any=20 > information contained in this e-mail is hereby excluded. If=20 > you are not the intended recipient, please notify the sender=20 > immediately, destroy the original transmission and its=20 > attachments and do not disclose the contents to any other=20 > person, use it for any purpose, or store or copy the=20 > information in any medium. Copyright in this e-mail and any=20 > attachments belongs to Alcatel-Lucent and/or its affiliated entities. > =09 > = From john.elwell@siemens-enterprise.com Mon Jan 17 00:20:24 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E19CA3A6EBA for ; Mon, 17 Jan 2011 00:20:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9eBRHWB-sHJ for ; Mon, 17 Jan 2011 00:20:21 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 4945B3A6EBB for ; Mon, 17 Jan 2011 00:20:21 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3018780 for siprec@ietf.org; Mon, 17 Jan 2011 09:22:42 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 702C81EB82B0 for ; Mon, 17 Jan 2011 09:22:42 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 17 Jan 2011 09:22:43 +0100 From: "Elwell, John" To: "siprec@ietf.org" Date: Mon, 17 Jan 2011 09:22:40 +0100 Thread-Topic: Inputs to draft-ietf-siprec-req-06 Thread-Index: AcuyUfJnU/vECby9TGaM0uRbXItGhAC8g4WgABTj8SAAIgSUIA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] FW: Inputs to draft-ietf-siprec-req-06 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 08:20:24 -0000 Forwarded on behalf of Dave Smith. > -----Original Message----- > From: Dave Smith [mailto:Dave.Smith@genesyslab.com]=20 > Sent: 16 January 2011 16:08 > To: Elwell, John > Subject: FW: Inputs to draft-ietf-siprec-req-06 >=20 > Hi John, >=20 > Can you please send this email out to the "siprec@ietf.org" email > address for me.=20 > Our Genesys email server is failing to send emails out to that address > again (in the mean time I will try to get it fixed through our > HelpDesk). >=20 > Thanks, > Dave >=20 >=20 > -----Original Message----- > From: Dave Smith=20 > Sent: Saturday, January 15, 2011 10:59 PM > To: Elwell, John; siprec@ietf.org > Subject: Inputs to draft-ietf-siprec-req-06 >=20 > Here are my inputs to the latest draft-ietf-siprec-req-06. =20 >=20 >=20 > 1. Recommend to change this: > o REQ-005 The mechanism MUST support the ability to record a CS > without an intentional loss of media (for example,=20 > clipping media at > the beginning of the CS) and without impacting the quality=20 > or timing > of the CS (for example, delaying the start of the CS while > preparation for recording takes place). See Use Case 4 in=20 > Section 5. >=20 > To this: > o REQ-005 The mechanism MUST support the ability to record a CS > without an unintentional loss of media (for example, clipping media > at > the beginning of the CS) and without impacting the quality=20 > or timing > of the CS (for example, delaying the start of the CS while > preparation for recording takes place). =20 >=20 > The use case is not referenced correctly and I don't see any reason to > refer to it (doesn't provide much additional info). Also corrected > "intentional" to "unintentional." >=20 >=20 > 2. Recommend to change this: > o REQ-018 The mechanism MUST provide a means of indicating to the > participants involved in a CS that their session is being recorded. >=20 > Examples include: inject tones into the CS from the SRC, play a > message at the beginning of a session, a visual indicator on a > display, etc. >=20 > To this: > o REQ-018 The mechanism MUST provide a means of indicating to the > participants involved in a CS that their session is currently being > recorded. >=20 > Examples include: inject tones into the CS from the SRC, a visual > indicator on a display >=20 > Added word "currently" because this is about providing an ongoing > indicator during the call. Removed the "play a message...." part > because playing a message at the beginning of a session is=20 > not a method > that would require a siprec protocol solution, it's n/a, it's=20 > not about > " an ongoing indicator." =20 >=20 >=20 > 3. Recommend to change this: > o REQ-013 The mechanism MUST provide the SRS with the means to > correlate RS media with CS participant media described in metadata. >=20 > To this: > o REQ-013 The mechanism MUST provide the SRS with the means to > correlate RS media with CS participant media. >=20 > This is recommended because I don't see the need for the part=20 > that read > "described in metadata" and because it is not clear what it meant. =20 >=20 >=20 > 4. Recommend to delete this Requirement: > o REQ-021 The mechanism MUST support means to relate Recording > Session(s) with Communication Session(s). >=20 > It is not needed since we have REQ-012 and REQ-013. =20 >=20 >=20 >=20 > Regards, > Dave >=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf > Of Elwell, John > Sent: Wednesday, January 12, 2011 4:12 AM > To: siprec@ietf.org > Subject: [siprec] Agenda requests plus reminder >=20 > Please let me have your agenda requests for the dual interim on > 25th/26th. >=20 > Also, a reminder that WGLC on siprec-req is into its second week and I > have not seen any responses yet. Even if you are happy with=20 > it as is, a > note to the list would be helpful. >=20 > John > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >=20 > =09 > -------------------------------------------------------------- > ---------- > ------------------------------------------- > CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain > confidential and proprietary information of Alcatel-Lucent and/or its > affiliated entities. Access by the intended recipient only is > authorized. Any liability arising from any party acting, or refraining > from acting, on any information contained in this e-mail is hereby > excluded. If you are not the intended recipient, please notify the > sender immediately, destroy the original transmission and its > attachments and do not disclose the contents to any other=20 > person, use it > for any purpose, or store or copy the information in any medium. > Copyright in this e-mail and any attachments belongs to Alcatel-Lucent > and/or its affiliated entities. > =09 >=20 > =09 > -------------------------------------------------------------- > ----------------------------------------------------- > CONFIDENTIALITY NOTICE: This e-mail and any files attached=20 > may contain confidential and proprietary information of=20 > Alcatel-Lucent and/or its affiliated entities. Access by the=20 > intended recipient only is authorized. Any liability arising=20 > from any party acting, or refraining from acting, on any=20 > information contained in this e-mail is hereby excluded. If=20 > you are not the intended recipient, please notify the sender=20 > immediately, destroy the original transmission and its=20 > attachments and do not disclose the contents to any other=20 > person, use it for any purpose, or store or copy the=20 > information in any medium. Copyright in this e-mail and any=20 > attachments belongs to Alcatel-Lucent and/or its affiliated entities. > =09 > = From john.elwell@siemens-enterprise.com Mon Jan 17 00:35:12 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 428283A6EC2 for ; Mon, 17 Jan 2011 00:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwqqNb5DZt6r for ; Mon, 17 Jan 2011 00:35:10 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 23DF73A6EC3 for ; Mon, 17 Jan 2011 00:35:09 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3024815 for siprec@ietf.org; Mon, 17 Jan 2011 09:37:42 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 6F74B23F028E for ; Mon, 17 Jan 2011 09:37:42 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 17 Jan 2011 09:37:43 +0100 From: "Elwell, John" To: "Elwell, John" , "siprec@ietf.org" Date: Mon, 17 Jan 2011 09:37:40 +0100 Thread-Topic: Inputs to draft-ietf-siprec-req-06 Thread-Index: AcuyUfJnU/vECby9TGaM0uRbXItGhAC8g4WgABTj8SAAIgSUIAAANi2w Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Inputs to draft-ietf-siprec-req-06 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 08:35:12 -0000 =20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: 17 January 2011 08:23 > To: siprec@ietf.org > Subject: [siprec] FW: Inputs to draft-ietf-siprec-req-06 >=20 > Forwarded on behalf of Dave Smith. >=20 > > -----Original Message----- > > From: Dave Smith [mailto:Dave.Smith@genesyslab.com]=20 > > Sent: 16 January 2011 16:08 > > To: Elwell, John > > Subject: FW: Inputs to draft-ietf-siprec-req-06 > >=20 > > Hi John, > >=20 > > Can you please send this email out to the "siprec@ietf.org" email > > address for me.=20 > > Our Genesys email server is failing to send emails out to=20 > that address > > again (in the mean time I will try to get it fixed through our > > HelpDesk). > >=20 > > Thanks, > > Dave > >=20 > >=20 > > -----Original Message----- > > From: Dave Smith=20 > > Sent: Saturday, January 15, 2011 10:59 PM > > To: Elwell, John; siprec@ietf.org > > Subject: Inputs to draft-ietf-siprec-req-06 > >=20 > > Here are my inputs to the latest draft-ietf-siprec-req-06. =20 > >=20 > >=20 > > 1. Recommend to change this: > > o REQ-005 The mechanism MUST support the ability to record a CS > > without an intentional loss of media (for example,=20 > > clipping media at > > the beginning of the CS) and without impacting the quality=20 > > or timing > > of the CS (for example, delaying the start of the CS while > > preparation for recording takes place). See Use Case 4 in=20 > > Section 5. > >=20 > > To this: > > o REQ-005 The mechanism MUST support the ability to record a CS > > without an unintentional loss of media (for example,=20 > clipping media > > at > > the beginning of the CS) and without impacting the quality=20 > > or timing > > of the CS (for example, delaying the start of the CS while > > preparation for recording takes place). =20 > >=20 > > The use case is not referenced correctly and I don't see=20 > any reason to > > refer to it (doesn't provide much additional info). Also corrected > > "intentional" to "unintentional." [JRE] The word "intentional" came from me a few months ago. Perhaps it was = the wrong word - I was trying to convey the fact that some mechanism might = frequently lead to clipping - the loss of media is kind of built into the m= echanism, so in that sense it would be "intentional". I don't think changin= g to "unintentional" is correct - we can't avoid unintentional loss of medi= a, e.g., through packet loss. I guess what we are really trying to achieve = is something like this: "The mechanism MUST support the ability to record a= CS without loss of media while preparation for recording takes place." > >=20 > >=20 > > 2. Recommend to change this: > > o REQ-018 The mechanism MUST provide a means of indicating to the > > participants involved in a CS that their session is=20 > being recorded. > >=20 > > Examples include: inject tones into the CS from the SRC, play a > > message at the beginning of a session, a visual indicator on a > > display, etc. > >=20 > > To this: > > o REQ-018 The mechanism MUST provide a means of indicating to the > > participants involved in a CS that their session is=20 > currently being > > recorded. > >=20 > > Examples include: inject tones into the CS from the SRC, a visual > > indicator on a display > >=20 > > Added word "currently" because this is about providing an ongoing > > indicator during the call. Removed the "play a message...." part > > because playing a message at the beginning of a session is=20 > > not a method > > that would require a siprec protocol solution, it's n/a, it's=20 > > not about > > " an ongoing indicator." =20 [JRE] The word "currently" was there, in my opinion, because playing a mess= age to indicate that recording might take place at some stage during the CS= is what frequently happens and is sufficient for regulatory purposes in so= me jurisdictions. I agree it would not require a SIPREC protocol solution. = Let's see what others say. John (as individual) > >=20 > >=20 > > 3. Recommend to change this: > > o REQ-013 The mechanism MUST provide the SRS with the means to > > correlate RS media with CS participant media described=20 > in metadata. > >=20 > > To this: > > o REQ-013 The mechanism MUST provide the SRS with the means to > > correlate RS media with CS participant media. > >=20 > > This is recommended because I don't see the need for the part=20 > > that read > > "described in metadata" and because it is not clear what it meant. =20 > >=20 > >=20 > > 4. Recommend to delete this Requirement: > > o REQ-021 The mechanism MUST support means to relate Recording > > Session(s) with Communication Session(s). > >=20 > > It is not needed since we have REQ-012 and REQ-013. =20 > >=20 > >=20 > >=20 > > Regards, > > Dave > >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org=20 > > [mailto:siprec-bounces@ietf.org] On Behalf > > Of Elwell, John > > Sent: Wednesday, January 12, 2011 4:12 AM > > To: siprec@ietf.org > > Subject: [siprec] Agenda requests plus reminder > >=20 > > Please let me have your agenda requests for the dual interim on > > 25th/26th. > >=20 > > Also, a reminder that WGLC on siprec-req is into its second=20 > week and I > > have not seen any responses yet. Even if you are happy with=20 > > it as is, a > > note to the list would be helpful. > >=20 > > John > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > >=20 > > =09 > > -------------------------------------------------------------- > > ---------- > > ------------------------------------------- > > CONFIDENTIALITY NOTICE: This e-mail and any files attached=20 > may contain > > confidential and proprietary information of Alcatel-Lucent=20 > and/or its > > affiliated entities. Access by the intended recipient only is > > authorized. Any liability arising from any party acting, or=20 > refraining > > from acting, on any information contained in this e-mail is hereby > > excluded. If you are not the intended recipient, please notify the > > sender immediately, destroy the original transmission and its > > attachments and do not disclose the contents to any other=20 > > person, use it > > for any purpose, or store or copy the information in any medium. > > Copyright in this e-mail and any attachments belongs to=20 > Alcatel-Lucent > > and/or its affiliated entities. > > =09 > >=20 > > =09 > > -------------------------------------------------------------- > > ----------------------------------------------------- > > CONFIDENTIALITY NOTICE: This e-mail and any files attached=20 > > may contain confidential and proprietary information of=20 > > Alcatel-Lucent and/or its affiliated entities. Access by the=20 > > intended recipient only is authorized. Any liability arising=20 > > from any party acting, or refraining from acting, on any=20 > > information contained in this e-mail is hereby excluded. If=20 > > you are not the intended recipient, please notify the sender=20 > > immediately, destroy the original transmission and its=20 > > attachments and do not disclose the contents to any other=20 > > person, use it for any purpose, or store or copy the=20 > > information in any medium. Copyright in this e-mail and any=20 > > attachments belongs to Alcatel-Lucent and/or its affiliated=20 > entities. > > =09 > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From partr@cisco.com Mon Jan 17 00:44:55 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F0723A6E66 for ; Mon, 17 Jan 2011 00:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.802 X-Spam-Level: X-Spam-Status: No, score=-9.802 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfkLt-D6L0aI for ; Mon, 17 Jan 2011 00:44:54 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E2A943A6D17 for ; Mon, 17 Jan 2011 00:44:53 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4EAA+RM02Q/khLgWdsb2JhbACkWhUBARYiJKcomEmFUASEbolb Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 17 Jan 2011 08:47:27 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p0H8lOh9005689 for ; Mon, 17 Jan 2011 08:47:26 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jan 2011 14:17:25 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jan 2011 14:17:25 +0530 Message-ID: In-Reply-To: <4D10C503.9010105@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] SIPREC Metadata model: Is it required to model streams that are not recorded ? Thread-Index: AcuhIjRhcnaoey6VSOmSz8MLyiwQYgU/tvTw References: <35BCE99A477D6A4986FB2216D8CF2CFD04CCB7FC@XMB-BGL-417.cisco.com> <4D10C503.9010105@cisco.com> From: "Parthasarathi R (partr)" To: "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 17 Jan 2011 08:47:25.0990 (UTC) FILETIME=[2A4B9C60:01CBB623] Subject: Re: [siprec] SIPREC Metadata model: Is it required to model streams that are not recorded ? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 08:44:55 -0000 Paul/John, IMO, the metadata shall contain rejected or non-recorded m-line information and recording session SDP have to carry non-recorded m-line information. I have another alternative approach in mind to solve this issue in Metadata. In case of media stream is not active in CS, Recording session has to carry non-active m-line (port 0 or a=3Dinactive) information with label attribute (RFC 4574) then the external document shall refer to m-line using label attribute. SRS shall understand about non-active stream by the analysis of SDP metadata. Here, the external document has no need to aware of the stream state. Thanks Partha=20 -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) Sent: Tuesday, December 21, 2010 8:47 PM To: siprec@ietf.org Subject: Re: [siprec] SIPREC Metadata model: Is it required to model streams that are not recorded ? On 12/21/2010 8:47 AM, Elwell, John wrote: > If additional media streams are offered to the SRS but declined, clearly the SRS knows of the existence of those streams. So I think the point behind the question is whether the SRS needs to know the subsequent fate of those additional streams in the CS, e.g., if they are held, resumed, disabled, etc.. One possibility is for the SRC to continue offering them even though they have been previously declined. However there is some cost to doing this, in maintaining media ports, possibly using ICE, etc. An alternative might be to send metadata about these hypothetical streams without any cross reference to the SDP. But that will require being careful that sufficient info is in the metadata without the SDP in the RS. Thanks, Paul > John > > >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) >> Sent: 21 December 2010 13:29 >> To: siprec@ietf.org >> Subject: [siprec] SIPREC Metadata model: Is it required to model=20 >> streams that are not recorded ? >> >> Hi all, >> >> >> >> During the SIPREC IETF dec 16th 2010 virtual interim we discussed in=20 >> brief about the need to model stream that are not recorded ( there=20 >> were people like Leon who have suggested on having this in the=20 >> model). >> >> >> >> e.g. SRC offered certain media types (like audio, video) but SRS=20 >> choose to accept only subset of them ( say only audio). >> >> The other possibility could be a CS might have multiple media=20 >> types(audio, video) but an SRC may record only one type (say >> audio) due to its limitations. However an SRS might want to know all=20 >> the streams of CS. >> >> >> >> If its required to model these information in metadata, how do we=20 >> do them ? >> >> >> >> I would like to get some thoughts/ inputs from interested people in=20 >> the mailing list on whether there is a value add / need in storing=20 >> information about streams that are not recorded. >> >> >> >> Regards, >> >> Ram >> >> > _______________________________________________ > 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 From partr@cisco.com Mon Jan 17 01:07:42 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E00128B56A for ; Mon, 17 Jan 2011 01:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.107 X-Spam-Level: X-Spam-Status: No, score=-10.107 tagged_above=-999 required=5 tests=[AWL=0.492, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pe8evbQj+kuQ for ; Mon, 17 Jan 2011 01:07:40 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 44C9F3A6ED5 for ; Mon, 17 Jan 2011 01:07:40 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4EADeWM02Q/khLgWdsb2JhbACkWhUBARYiJKclmE2FUASEbolb Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 17 Jan 2011 09:10:13 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p0H99Bpx010349; Mon, 17 Jan 2011 09:10:13 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jan 2011 14:38:54 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jan 2011 14:38:54 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Inputs to draft-ietf-siprec-req-06 Thread-Index: AcuyUfJnU/vECby9TGaM0uRbXItGhAC8g4WgABTj8SAAIgSUIAAANi2wAADxo7A= References: From: "Parthasarathi R (partr)" To: "Elwell, John" , X-OriginalArrivalTime: 17 Jan 2011 09:08:54.0727 (UTC) FILETIME=[2A714570:01CBB626] Subject: Re: [siprec] Inputs to draft-ietf-siprec-req-06 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 09:07:42 -0000 Please read inline=20 -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John Sent: Monday, January 17, 2011 2:08 PM To: Elwell, John; siprec@ietf.org Subject: Re: [siprec] Inputs to draft-ietf-siprec-req-06 =20 > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: 17 January 2011 08:23 > To: siprec@ietf.org > Subject: [siprec] FW: Inputs to draft-ietf-siprec-req-06 >=20 > Forwarded on behalf of Dave Smith. >=20 > > -----Original Message----- > > From: Dave Smith [mailto:Dave.Smith@genesyslab.com] > > Sent: 16 January 2011 16:08 > > To: Elwell, John > > Subject: FW: Inputs to draft-ietf-siprec-req-06 > >=20 > > Hi John, > >=20 > > Can you please send this email out to the "siprec@ietf.org" email=20 > > address for me. > > Our Genesys email server is failing to send emails out to > that address > > again (in the mean time I will try to get it fixed through our=20 > > HelpDesk). > >=20 > > Thanks, > > Dave > >=20 > >=20 > > -----Original Message----- > > From: Dave Smith > > Sent: Saturday, January 15, 2011 10:59 PM > > To: Elwell, John; siprec@ietf.org > > Subject: Inputs to draft-ietf-siprec-req-06 > >=20 > > Here are my inputs to the latest draft-ietf-siprec-req-06. =20 > >=20 > >=20 > > 1. Recommend to change this: > > o REQ-005 The mechanism MUST support the ability to record a CS > > without an intentional loss of media (for example, clipping media > > at > > the beginning of the CS) and without impacting the quality or=20 > > timing > > of the CS (for example, delaying the start of the CS while > > preparation for recording takes place). See Use Case 4 in=20 > > Section 5. > >=20 > > To this: > > o REQ-005 The mechanism MUST support the ability to record a CS > > without an unintentional loss of media (for example, > clipping media > > at > > the beginning of the CS) and without impacting the quality or=20 > > timing > > of the CS (for example, delaying the start of the CS while > > preparation for recording takes place). =20 > >=20 > > The use case is not referenced correctly and I don't see > any reason to > > refer to it (doesn't provide much additional info). Also corrected=20 > > "intentional" to "unintentional." [JRE] The word "intentional" came from me a few months ago. Perhaps it was the wrong word - I was trying to convey the fact that some mechanism might frequently lead to clipping - the loss of media is kind of built into the mechanism, so in that sense it would be "intentional". I don't think changing to "unintentional" is correct - we can't avoid unintentional loss of media, e.g., through packet loss. I guess what we are really trying to achieve is something like this: "The mechanism MUST support the ability to record a CS without loss of media while preparation for recording takes place." IMO, without any loss of media may lead to inefficient system in few deployment. For example, CS dialog is established whereas RS is taking more time to establish due to network delay between SRC and SRS, then it may be preferred in few deployment to loss some media instead of delaying CS establishment and some other deployment may prefer to wait for RS establishment. The current requirement wording indicates that CS dialog establishment MUST be delayed for RS establishment. =20 > >=20 > >=20 > > 2. Recommend to change this: > > o REQ-018 The mechanism MUST provide a means of indicating to the > > participants involved in a CS that their session is > being recorded. > >=20 > > Examples include: inject tones into the CS from the SRC, play a > > message at the beginning of a session, a visual indicator on a > > display, etc. > >=20 > > To this: > > o REQ-018 The mechanism MUST provide a means of indicating to the > > participants involved in a CS that their session is > currently being > > recorded. > >=20 > > Examples include: inject tones into the CS from the SRC, a visual > > indicator on a display > >=20 > > Added word "currently" because this is about providing an ongoing=20 > > indicator during the call. Removed the "play a message...." part=20 > > because playing a message at the beginning of a session is not a=20 > > method that would require a siprec protocol solution, it's n/a, it's > > not about " an ongoing indicator." [JRE] The word "currently" was there, in my opinion, because playing a message to indicate that recording might take place at some stage during the CS is what frequently happens and is sufficient for regulatory purposes in some jurisdictions. I agree it would not require a SIPREC protocol solution. Let's see what others say. I agree with John that playing a message meet some of the Jurisdictions requirement. I like to hear from Dave whether any jurisdiction mandates for "injection tone" or "visual display". Thanks Partha John (as individual) > >=20 > >=20 > > 3. Recommend to change this: > > o REQ-013 The mechanism MUST provide the SRS with the means to > > correlate RS media with CS participant media described > in metadata. > >=20 > > To this: > > o REQ-013 The mechanism MUST provide the SRS with the means to > > correlate RS media with CS participant media. > >=20 > > This is recommended because I don't see the need for the part that=20 > > read "described in metadata" and because it is not clear what it=20 > > meant. > >=20 > >=20 > > 4. Recommend to delete this Requirement: > > o REQ-021 The mechanism MUST support means to relate Recording > > Session(s) with Communication Session(s). > >=20 > > It is not needed since we have REQ-012 and REQ-013. =20 > >=20 > >=20 > >=20 > > Regards, > > Dave > >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: Wednesday, January 12, 2011 4:12 AM > > To: siprec@ietf.org > > Subject: [siprec] Agenda requests plus reminder > >=20 > > Please let me have your agenda requests for the dual interim on=20 > > 25th/26th. > >=20 > > Also, a reminder that WGLC on siprec-req is into its second > week and I > > have not seen any responses yet. Even if you are happy with it as=20 > > is, a note to the list would be helpful. > >=20 > > John > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > >=20 > > =09 > > -------------------------------------------------------------- > > ---------- > > ------------------------------------------- > > CONFIDENTIALITY NOTICE: This e-mail and any files attached > may contain > > confidential and proprietary information of Alcatel-Lucent > and/or its > > affiliated entities. Access by the intended recipient only is=20 > > authorized. Any liability arising from any party acting, or > refraining > > from acting, on any information contained in this e-mail is hereby=20 > > excluded. If you are not the intended recipient, please notify the=20 > > sender immediately, destroy the original transmission and its=20 > > attachments and do not disclose the contents to any other person,=20 > > use it for any purpose, or store or copy the information in any=20 > > medium. > > Copyright in this e-mail and any attachments belongs to > Alcatel-Lucent > > and/or its affiliated entities. > > =09 > >=20 > > =09 > > -------------------------------------------------------------- > > ----------------------------------------------------- > > CONFIDENTIALITY NOTICE: This e-mail and any files attached may=20 > > contain confidential and proprietary information of Alcatel-Lucent=20 > > and/or its affiliated entities. Access by the intended recipient=20 > > only is authorized. Any liability arising from any party acting, or=20 > > refraining from acting, on any information contained in this e-mail=20 > > is hereby excluded. If you are not the intended recipient, please=20 > > notify the sender immediately, destroy the original transmission and > > its attachments and do not disclose the contents to any other=20 > > person, use it for any purpose, or store or copy the information in=20 > > any medium. Copyright in this e-mail and any attachments belongs to=20 > > Alcatel-Lucent and/or its affiliated > entities. > > =09 > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >=20 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Mon Jan 17 02:58:55 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44BB828C0D9 for ; Mon, 17 Jan 2011 02:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVr1nfepuO7S for ; Mon, 17 Jan 2011 02:58:54 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 7CE3E3A6E71 for ; Mon, 17 Jan 2011 02:58:53 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3031062; Mon, 17 Jan 2011 12:01:26 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id A3A4623F0278; Mon, 17 Jan 2011 12:01:26 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 17 Jan 2011 12:01:26 +0100 From: "Elwell, John" To: "Parthasarathi R (partr)" , "siprec@ietf.org" Date: Mon, 17 Jan 2011 12:01:24 +0100 Thread-Topic: [siprec] Inputs to draft-ietf-siprec-req-06 Thread-Index: AcuyUfJnU/vECby9TGaM0uRbXItGhAC8g4WgABTj8SAAIgSUIAAANi2wAADxo7AABC4GcA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Inputs to draft-ietf-siprec-req-06 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 10:58:55 -0000 =20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 > Sent: 17 January 2011 09:09 > To: Elwell, John; siprec@ietf.org > Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06 >=20 > Please read inline=20 >=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf > Of Elwell, John > Sent: Monday, January 17, 2011 2:08 PM > To: Elwell, John; siprec@ietf.org > Subject: Re: [siprec] Inputs to draft-ietf-siprec-req-06 >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: 17 January 2011 08:23 > > To: siprec@ietf.org > > Subject: [siprec] FW: Inputs to draft-ietf-siprec-req-06 > >=20 > > Forwarded on behalf of Dave Smith. > >=20 > > > -----Original Message----- > > > From: Dave Smith [mailto:Dave.Smith@genesyslab.com] > > > Sent: 16 January 2011 16:08 > > > To: Elwell, John > > > Subject: FW: Inputs to draft-ietf-siprec-req-06 > > >=20 > > > Hi John, > > >=20 > > > Can you please send this email out to the "siprec@ietf.org" email=20 > > > address for me. > > > Our Genesys email server is failing to send emails out to > > that address > > > again (in the mean time I will try to get it fixed through our=20 > > > HelpDesk). > > >=20 > > > Thanks, > > > Dave > > >=20 > > >=20 > > > -----Original Message----- > > > From: Dave Smith > > > Sent: Saturday, January 15, 2011 10:59 PM > > > To: Elwell, John; siprec@ietf.org > > > Subject: Inputs to draft-ietf-siprec-req-06 > > >=20 > > > Here are my inputs to the latest draft-ietf-siprec-req-06. =20 > > >=20 > > >=20 > > > 1. Recommend to change this: > > > o REQ-005 The mechanism MUST support the ability to record a CS > > > without an intentional loss of media (for example,=20 > clipping media >=20 > > > at > > > the beginning of the CS) and without impacting the quality or=20 > > > timing > > > of the CS (for example, delaying the start of the CS while > > > preparation for recording takes place). See Use Case 4 in=20 > > > Section 5. > > >=20 > > > To this: > > > o REQ-005 The mechanism MUST support the ability to record a CS > > > without an unintentional loss of media (for example, > > clipping media > > > at > > > the beginning of the CS) and without impacting the quality or=20 > > > timing > > > of the CS (for example, delaying the start of the CS while > > > preparation for recording takes place). =20 > > >=20 > > > The use case is not referenced correctly and I don't see > > any reason to > > > refer to it (doesn't provide much additional info). Also=20 > corrected=20 > > > "intentional" to "unintentional." > [JRE] The word "intentional" came from me a few months ago. Perhaps it > was the wrong word - I was trying to convey the fact that=20 > some mechanism > might frequently lead to clipping - the loss of media is kind of built > into the mechanism, so in that sense it would be=20 > "intentional". I don't > think changing to "unintentional" is correct - we can't avoid > unintentional loss of media, e.g., through packet loss. I=20 > guess what we > are really trying to achieve is something like this: "The=20 > mechanism MUST > support the ability to record a CS without loss of media while > preparation for recording takes place." >=20 > IMO, without any loss of media may lead to inefficient system > in few deployment. For example, CS dialog is established whereas RS is > taking more time to establish due to network delay between=20 > SRC and SRS, > then it may be preferred in few deployment to loss some media=20 > instead of > delaying CS establishment and some other deployment may prefer to wait > for RS establishment. The current requirement wording=20 > indicates that CS > dialog establishment MUST be delayed for RS establishment. =20 [JRE] No, I believe it was not intended to force the CS to be delayed. A me= chanism that would meet this requirement without delaying CS establishment = would be to keep an RS permanently established, even when there is no CS, s= o that it can immediately be used when a new CS starts. This was the persis= tent recording use case (4), which I believe some people felt was needed fo= r some environments, and hence the desire to capture requirements that such= environments have. Clearly we have failed to capture that requirements ade= quately - we need the right words. John (as individual) >=20 > > >=20 > > >=20 > > > 2. Recommend to change this: > > > o REQ-018 The mechanism MUST provide a means of=20 > indicating to the > > > participants involved in a CS that their session is > > being recorded. > > >=20 > > > Examples include: inject tones into the CS from the SRC, play a > > > message at the beginning of a session, a visual indicator on a > > > display, etc. > > >=20 > > > To this: > > > o REQ-018 The mechanism MUST provide a means of=20 > indicating to the > > > participants involved in a CS that their session is > > currently being > > > recorded. > > >=20 > > > Examples include: inject tones into the CS from the=20 > SRC, a visual >=20 > > > indicator on a display > > >=20 > > > Added word "currently" because this is about providing an ongoing=20 > > > indicator during the call. Removed the "play a message...." part=20 > > > because playing a message at the beginning of a session is not a=20 > > > method that would require a siprec protocol solution,=20 > it's n/a, it's >=20 > > > not about " an ongoing indicator." > [JRE] The word "currently" was there, in my opinion, because playing a > message to indicate that recording might take place at some=20 > stage during > the CS is what frequently happens and is sufficient for regulatory > purposes in some jurisdictions. I agree it would not require a SIPREC > protocol solution. Let's see what others say. > I agree with John that playing a message meet some of the > Jurisdictions requirement. I like to hear from Dave whether any > jurisdiction mandates for "injection tone" or "visual display". > >=20 > Thanks > Partha >=20 > John (as individual) >=20 > > >=20 > > >=20 > > > 3. Recommend to change this: > > > o REQ-013 The mechanism MUST provide the SRS with the means to > > > correlate RS media with CS participant media described > > in metadata. > > >=20 > > > To this: > > > o REQ-013 The mechanism MUST provide the SRS with the means to > > > correlate RS media with CS participant media. > > >=20 > > > This is recommended because I don't see the need for the=20 > part that=20 > > > read "described in metadata" and because it is not clear what it=20 > > > meant. > > >=20 > > >=20 > > > 4. Recommend to delete this Requirement: > > > o REQ-021 The mechanism MUST support means to relate Recording > > > Session(s) with Communication Session(s). > > >=20 > > > It is not needed since we have REQ-012 and REQ-013. =20 > > >=20 > > >=20 > > >=20 > > > Regards, > > > Dave > > >=20 > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > > Sent: Wednesday, January 12, 2011 4:12 AM > > > To: siprec@ietf.org > > > Subject: [siprec] Agenda requests plus reminder > > >=20 > > > Please let me have your agenda requests for the dual interim on=20 > > > 25th/26th. > > >=20 > > > Also, a reminder that WGLC on siprec-req is into its second > > week and I > > > have not seen any responses yet. Even if you are happy with it as=20 > > > is, a note to the list would be helpful. > > >=20 > > > John > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > >=20 > > > =09 > > > -------------------------------------------------------------- > > > ---------- > > > ------------------------------------------- > > > CONFIDENTIALITY NOTICE: This e-mail and any files attached > > may contain > > > confidential and proprietary information of Alcatel-Lucent > > and/or its > > > affiliated entities. Access by the intended recipient only is=20 > > > authorized. Any liability arising from any party acting, or > > refraining > > > from acting, on any information contained in this e-mail=20 > is hereby=20 > > > excluded. If you are not the intended recipient, please=20 > notify the=20 > > > sender immediately, destroy the original transmission and its=20 > > > attachments and do not disclose the contents to any other person,=20 > > > use it for any purpose, or store or copy the information in any=20 > > > medium. > > > Copyright in this e-mail and any attachments belongs to > > Alcatel-Lucent > > > and/or its affiliated entities. > > > =09 > > >=20 > > > =09 > > > -------------------------------------------------------------- > > > ----------------------------------------------------- > > > CONFIDENTIALITY NOTICE: This e-mail and any files attached may=20 > > > contain confidential and proprietary information of=20 > Alcatel-Lucent=20 > > > and/or its affiliated entities. Access by the intended recipient=20 > > > only is authorized. Any liability arising from any party=20 > acting, or=20 > > > refraining from acting, on any information contained in=20 > this e-mail=20 > > > is hereby excluded. If you are not the intended recipient, please=20 > > > notify the sender immediately, destroy the original=20 > transmission and >=20 > > > its attachments and do not disclose the contents to any other=20 > > > person, use it for any purpose, or store or copy the=20 > information in=20 > > > any medium. Copyright in this e-mail and any attachments=20 > belongs to=20 > > > Alcatel-Lucent and/or its affiliated > > entities. > > > =09 > > >=20 > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From partr@cisco.com Mon Jan 17 06:32:16 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB90A28C0FE for ; Mon, 17 Jan 2011 06:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.119 X-Spam-Level: X-Spam-Status: No, score=-10.119 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neCZcu3MZpWP for ; Mon, 17 Jan 2011 06:32:15 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 402C628C0F8 for ; Mon, 17 Jan 2011 06:32:14 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8EACfiM02Q/khLgWdsb2JhbACkUxUBARYiJKdSmHqFUASEbolb Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 17 Jan 2011 14:34:47 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p0HEYj9O023059; Mon, 17 Jan 2011 14:34:47 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jan 2011 20:04:46 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jan 2011 20:04:43 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Inputs to draft-ietf-siprec-req-06 Thread-Index: AcuyUfJnU/vECby9TGaM0uRbXItGhAC8g4WgABTj8SAAIgSUIAAANi2wAADxo7AABC4GcAAGsDKw References: From: "Parthasarathi R (partr)" To: "Elwell, John" , X-OriginalArrivalTime: 17 Jan 2011 14:34:46.0189 (UTC) FILETIME=[B0059DD0:01CBB653] Cc: Dave Smith Subject: Re: [siprec] Inputs to draft-ietf-siprec-req-06 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 14:32:16 -0000 John/David, I'm fine with REQ-5 as long as the intention is to avoid initial clipping in recording using persistent RS or similar SIPREC proposed mechanism. Just, I'm trying to reword for this requirement: o REQ-005 The mechanism MUST support the ability to record a CS without loss of media (for example, clipping media at the beginning of the CS) due to RS recording preparation and also, without impacting the quality or timing of the CS (for example, delaying the start of the CS while preparation for recording session). See Use Case 4 in Section 4 for more details.=20 --- Removed: "intentional" --- Added: "due to RS recording preparation and also" Please let me know your opinion. Thanks Partha -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Monday, January 17, 2011 4:31 PM To: Parthasarathi R (partr); siprec@ietf.org Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06 =20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 17 January 2011 09:09 > To: Elwell, John; siprec@ietf.org > Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06 >=20 > Please read inline >=20 > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Monday, January 17, 2011 2:08 PM > To: Elwell, John; siprec@ietf.org > Subject: Re: [siprec] Inputs to draft-ietf-siprec-req-06 >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: 17 January 2011 08:23 > > To: siprec@ietf.org > > Subject: [siprec] FW: Inputs to draft-ietf-siprec-req-06 > >=20 > > Forwarded on behalf of Dave Smith. > >=20 > > > -----Original Message----- > > > From: Dave Smith [mailto:Dave.Smith@genesyslab.com] > > > Sent: 16 January 2011 16:08 > > > To: Elwell, John > > > Subject: FW: Inputs to draft-ietf-siprec-req-06 > > >=20 > > > Hi John, > > >=20 > > > Can you please send this email out to the "siprec@ietf.org" email=20 > > > address for me. > > > Our Genesys email server is failing to send emails out to > > that address > > > again (in the mean time I will try to get it fixed through our=20 > > > HelpDesk). > > >=20 > > > Thanks, > > > Dave > > >=20 > > >=20 > > > -----Original Message----- > > > From: Dave Smith > > > Sent: Saturday, January 15, 2011 10:59 PM > > > To: Elwell, John; siprec@ietf.org > > > Subject: Inputs to draft-ietf-siprec-req-06 > > >=20 > > > Here are my inputs to the latest draft-ietf-siprec-req-06. =20 > > >=20 > > >=20 > > > 1. Recommend to change this: > > > o REQ-005 The mechanism MUST support the ability to record a CS > > > without an intentional loss of media (for example,=20 > clipping media >=20 > > > at > > > the beginning of the CS) and without impacting the quality or=20 > > > timing > > > of the CS (for example, delaying the start of the CS while > > > preparation for recording takes place). See Use Case 4 in=20 > > > Section 5. > > >=20 > > > To this: > > > o REQ-005 The mechanism MUST support the ability to record a CS > > > without an unintentional loss of media (for example, > > clipping media > > > at > > > the beginning of the CS) and without impacting the quality or=20 > > > timing > > > of the CS (for example, delaying the start of the CS while > > > preparation for recording takes place). =20 > > >=20 > > > The use case is not referenced correctly and I don't see > > any reason to > > > refer to it (doesn't provide much additional info). Also=20 > corrected=20 > > > "intentional" to "unintentional." > [JRE] The word "intentional" came from me a few months ago. Perhaps it > was the wrong word - I was trying to convey the fact that=20 > some mechanism > might frequently lead to clipping - the loss of media is kind of built > into the mechanism, so in that sense it would be=20 > "intentional". I don't > think changing to "unintentional" is correct - we can't avoid > unintentional loss of media, e.g., through packet loss. I=20 > guess what we > are really trying to achieve is something like this: "The=20 > mechanism MUST > support the ability to record a CS without loss of media while > preparation for recording takes place." >=20 > IMO, without any loss of media may lead to inefficient system > in few deployment. For example, CS dialog is established whereas RS is > taking more time to establish due to network delay between=20 > SRC and SRS, > then it may be preferred in few deployment to loss some media=20 > instead of > delaying CS establishment and some other deployment may prefer to wait > for RS establishment. The current requirement wording=20 > indicates that CS > dialog establishment MUST be delayed for RS establishment. =20 [JRE] No, I believe it was not intended to force the CS to be delayed. A mechanism that would meet this requirement without delaying CS establishment would be to keep an RS permanently established, even when there is no CS, so that it can immediately be used when a new CS starts. This was the persistent recording use case (4), which I believe some people felt was needed for some environments, and hence the desire to capture requirements that such environments have. Clearly we have failed to capture that requirements adequately - we need the right words. John (as individual) >=20 > > >=20 > > >=20 > > > 2. Recommend to change this: > > > o REQ-018 The mechanism MUST provide a means of=20 > indicating to the > > > participants involved in a CS that their session is > > being recorded. > > >=20 > > > Examples include: inject tones into the CS from the SRC, play a > > > message at the beginning of a session, a visual indicator on a > > > display, etc. > > >=20 > > > To this: > > > o REQ-018 The mechanism MUST provide a means of=20 > indicating to the > > > participants involved in a CS that their session is > > currently being > > > recorded. > > >=20 > > > Examples include: inject tones into the CS from the=20 > SRC, a visual >=20 > > > indicator on a display > > >=20 > > > Added word "currently" because this is about providing an ongoing=20 > > > indicator during the call. Removed the "play a message...." part=20 > > > because playing a message at the beginning of a session is not a=20 > > > method that would require a siprec protocol solution,=20 > it's n/a, it's >=20 > > > not about " an ongoing indicator." > [JRE] The word "currently" was there, in my opinion, because playing a > message to indicate that recording might take place at some=20 > stage during > the CS is what frequently happens and is sufficient for regulatory > purposes in some jurisdictions. I agree it would not require a SIPREC > protocol solution. Let's see what others say. > I agree with John that playing a message meet some of the > Jurisdictions requirement. I like to hear from Dave whether any > jurisdiction mandates for "injection tone" or "visual display". > >=20 > Thanks > Partha >=20 > John (as individual) >=20 > > >=20 > > >=20 > > > 3. Recommend to change this: > > > o REQ-013 The mechanism MUST provide the SRS with the means to > > > correlate RS media with CS participant media described > > in metadata. > > >=20 > > > To this: > > > o REQ-013 The mechanism MUST provide the SRS with the means to > > > correlate RS media with CS participant media. > > >=20 > > > This is recommended because I don't see the need for the=20 > part that=20 > > > read "described in metadata" and because it is not clear what it=20 > > > meant. > > >=20 > > >=20 > > > 4. Recommend to delete this Requirement: > > > o REQ-021 The mechanism MUST support means to relate Recording > > > Session(s) with Communication Session(s). > > >=20 > > > It is not needed since we have REQ-012 and REQ-013. =20 > > >=20 > > >=20 > > >=20 > > > Regards, > > > Dave > > >=20 > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > > Sent: Wednesday, January 12, 2011 4:12 AM > > > To: siprec@ietf.org > > > Subject: [siprec] Agenda requests plus reminder > > >=20 > > > Please let me have your agenda requests for the dual interim on=20 > > > 25th/26th. > > >=20 > > > Also, a reminder that WGLC on siprec-req is into its second > > week and I > > > have not seen any responses yet. Even if you are happy with it as=20 > > > is, a note to the list would be helpful. > > >=20 > > > John > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > >=20 > > > =09 > > > -------------------------------------------------------------- > > > ---------- > > > ------------------------------------------- > > > CONFIDENTIALITY NOTICE: This e-mail and any files attached > > may contain > > > confidential and proprietary information of Alcatel-Lucent > > and/or its > > > affiliated entities. Access by the intended recipient only is=20 > > > authorized. Any liability arising from any party acting, or > > refraining > > > from acting, on any information contained in this e-mail=20 > is hereby=20 > > > excluded. If you are not the intended recipient, please=20 > notify the=20 > > > sender immediately, destroy the original transmission and its=20 > > > attachments and do not disclose the contents to any other person,=20 > > > use it for any purpose, or store or copy the information in any=20 > > > medium. > > > Copyright in this e-mail and any attachments belongs to > > Alcatel-Lucent > > > and/or its affiliated entities. > > > =09 > > >=20 > > > =09 > > > -------------------------------------------------------------- > > > ----------------------------------------------------- > > > CONFIDENTIALITY NOTICE: This e-mail and any files attached may=20 > > > contain confidential and proprietary information of=20 > Alcatel-Lucent=20 > > > and/or its affiliated entities. Access by the intended recipient=20 > > > only is authorized. Any liability arising from any party=20 > acting, or=20 > > > refraining from acting, on any information contained in=20 > this e-mail=20 > > > is hereby excluded. If you are not the intended recipient, please=20 > > > notify the sender immediately, destroy the original=20 > transmission and >=20 > > > its attachments and do not disclose the contents to any other=20 > > > person, use it for any purpose, or store or copy the=20 > information in=20 > > > any medium. Copyright in this e-mail and any attachments=20 > belongs to=20 > > > Alcatel-Lucent and/or its affiliated > > entities. > > > =09 > > >=20 > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >=20 From Henry.Lum@alcatel-lucent.com Mon Jan 17 07:41:58 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA9513A6F43 for ; Mon, 17 Jan 2011 07:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.92 X-Spam-Level: X-Spam-Status: No, score=-5.92 tagged_above=-999 required=5 tests=[AWL=0.679, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYXEY-m9YxWB for ; Mon, 17 Jan 2011 07:41:58 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id C93F43A6F42 for ; Mon, 17 Jan 2011 07:41:57 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p0HFiTov024301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 17 Jan 2011 09:44:29 -0600 (CST) Received: from relay-out2.dc (relay-out2.dc.genesyslab.com [172.22.68.188]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0HFiRKN029778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 17 Jan 2011 09:44:28 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc (8.13.8+Sun/8.13.8) with ESMTP id p0HFiQPj018692 for ; Mon, 17 Jan 2011 07:44:26 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jan 2011 07:44:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 17 Jan 2011 07:44:25 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF74069044E3@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-portman-siprec-protocol-02 Thread-Index: Acu2XJ/a3bs08sb6SgGQW9XVUrwbQgAADNuA From: "Henry Lum" To: X-OriginalArrivalTime: 17 Jan 2011 15:44:26.0726 (UTC) FILETIME=[6BD0F060:01CBB65D] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: [siprec] FW: New Version Notification for draft-portman-siprec-protocol-02 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 15:41:58 -0000 SGksDQoNCkFmdGVyIHdvcmtpbmcgd2l0aCB0aGUgYXV0aG9ycyBvZiBkcmFmdC1qb2huc3Rvbi1z aXByZWMtY2MtcmVjLCB3ZSBoYXZlIGRlY2lkZWQgdG8gbWVyZ2Ugc29tZSBvZiB0aGUgY29yZSBh c3BlY3RzIGludG8gdGhpcyBkcmFmdCwgbm93IC0wMi4NCg0KUmVnYXJkcywNCkhlbnJ5DQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJRVRGIEktRCBTdWJtaXNzaW9uIFRvb2wg W21haWx0bzppZHN1Ym1pc3Npb25AaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDE3 LCAyMDExIDEwOjM2IEFNDQpUbzogSGVucnkgTHVtDQpDYzogbGVvbi5wb3J0bWFuQG5pY2UuY29t OyBhbGFuLmIuam9obnN0b25AZ21haWwuY29tOyBhbmRyZXcuaHV0dG9uQHNpZW1lbnMtZW50ZXJw cmlzZS5jb20NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcG9y dG1hbi1zaXByZWMtcHJvdG9jb2wtMDIgDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0 LXBvcnRtYW4tc2lwcmVjLXByb3RvY29sLTAyLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IEhlbnJ5IEx1bSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoN CkZpbGVuYW1lOgkgZHJhZnQtcG9ydG1hbi1zaXByZWMtcHJvdG9jb2wNClJldmlzaW9uOgkgMDIN ClRpdGxlOgkJIFRoZSBTSVAtYmFzZWQgTWVkaWEgUmVjb3JkaW5nIFByb3RvY29sIChTSVBSRUMp DQpDcmVhdGlvbl9kYXRlOgkgMjAxMS0wMS0xNw0KV0cgSUQ6CQkgSW5kZXBlbmRlbnQgU3VibWlz c2lvbg0KTnVtYmVyX29mX3BhZ2VzOiAyMA0KDQpBYnN0cmFjdDoNClNJUFJFQyBTZXNzaW9uIFJl Y29yZGluZyBQcm90b2NvbCBpcyB1c2VkIGZvciBlc3RhYmxpc2hpbmcgcmVjb3JkaW5nDQpzZXNz aW9uIGFuZCByZXBvcnRpbmcgb2YgdGhlIG1ldGFkYXRhIG9mIHRoZSBjb21tdW5pY2F0aW9uIHNl c3Npb24uDQoNClRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSBTSVBSRUMgUHJvdG9jb2wgKFNJ UFJFQykuICBTSVBSRUMgaXMgdXNlZA0KYmV0d2VlbiBTZXNzaW9uIFJlY29yZGluZyBDbGllbnQg KFNSQykgYW5kIFNlc3Npb24gUmVjb3JkaW5nIFNlcnZlcg0KKFNSUykuDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQuDQoNCg0KDQoJCQkJCQ0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlLW1haWwgYW5kIGFueSBmaWxlcyBhdHRhY2hl ZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uIG9m IEFsY2F0ZWwtTHVjZW50IGFuZC9vciBpdHMgYWZmaWxpYXRlZCBlbnRpdGllcy4gQWNjZXNzIGJ5 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb25seSBpcyBhdXRob3JpemVkLiBBbnkgbGlhYmlsaXR5 IGFyaXNpbmcgZnJvbSBhbnkgcGFydHkgYWN0aW5nLCBvciByZWZyYWluaW5nIGZyb20gYWN0aW5n LCBvbiBhbnkgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgZS1tYWlsIGlzIGhlcmVieSBl eGNsdWRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5LCBkZXN0cm95IHRoZSBvcmlnaW5hbCB0cmFuc21p c3Npb24gYW5kIGl0cyBhdHRhY2htZW50cyBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50 cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBv ciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBDb3B5cmlnaHQgaW4gdGhpcyBl LW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBiZWxvbmdzIHRvIEFsY2F0ZWwtTHVjZW50IGFuZC9v ciBpdHMgYWZmaWxpYXRlZCBlbnRpdGllcy4NCgkJCQkJDQo= From pkyzivat@cisco.com Mon Jan 17 08:03:02 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B83833A6D45 for ; Mon, 17 Jan 2011 08:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.228 X-Spam-Level: X-Spam-Status: No, score=-110.228 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEhUTBROz2K6 for ; Mon, 17 Jan 2011 08:03:01 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8F4933A6BD8 for ; Mon, 17 Jan 2011 08:03:01 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 17 Jan 2011 16:05:34 +0000 Received: from [10.86.241.224] (che-vpn-cluster-1-479.cisco.com [10.86.241.224]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0HG5YDV009349; Mon, 17 Jan 2011 16:05:34 GMT Message-ID: <4D3468CD.5030703@cisco.com> Date: Mon, 17 Jan 2011 11:05:33 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Parthasarathi R (partr)" References: <35BCE99A477D6A4986FB2216D8CF2CFD04CCB7FC@XMB-BGL-417.cisco.com> <4D10C503.9010105@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] SIPREC Metadata model: Is it required to model streams that are not recorded ? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 16:03:02 -0000 On 1/17/2011 3:47 AM, Parthasarathi R (partr) wrote: > Paul/John, > > IMO, the metadata shall contain rejected or non-recorded m-line > information and recording session SDP have to carry non-recorded m-line > information. > > I have another alternative approach in mind to solve this issue in > Metadata. In case of media stream is not active in CS, Recording session > has to carry non-active m-line (port 0 or a=inactive) information with > label attribute (RFC 4574) then the external document shall refer to > m-line using label attribute. SRS shall understand about non-active > stream by the analysis of SDP metadata. Here, the external document has > no need to aware of the stream state. This approach seems workable to me. Thanks, Paul > Thanks > Partha > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Paul Kyzivat (pkyzivat) > Sent: Tuesday, December 21, 2010 8:47 PM > To: siprec@ietf.org > Subject: Re: [siprec] SIPREC Metadata model: Is it required to model > streams that are not recorded ? > > > > On 12/21/2010 8:47 AM, Elwell, John wrote: >> If additional media streams are offered to the SRS but declined, > clearly the SRS knows of the existence of those streams. So I think the > point behind the question is whether the SRS needs to know the > subsequent fate of those additional streams in the CS, e.g., if they are > held, resumed, disabled, etc.. > > One possibility is for the SRC to continue offering them even though > they have been previously declined. However there is some cost to doing > this, in maintaining media ports, possibly using ICE, etc. > > An alternative might be to send metadata about these hypothetical > streams without any cross reference to the SDP. But that will require > being careful that sufficient info is in the metadata without the SDP in > the RS. > > Thanks, > Paul > >> John >> >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) >>> Sent: 21 December 2010 13:29 >>> To: siprec@ietf.org >>> Subject: [siprec] SIPREC Metadata model: Is it required to model >>> streams that are not recorded ? >>> >>> Hi all, >>> >>> >>> >>> During the SIPREC IETF dec 16th 2010 virtual interim we discussed in >>> brief about the need to model stream that are not recorded ( there >>> were people like Leon who have suggested on having this in the >>> model). >>> >>> >>> >>> e.g. SRC offered certain media types (like audio, video) but SRS >>> choose to accept only subset of them ( say only audio). >>> >>> The other possibility could be a CS might have multiple media >>> types(audio, video) but an SRC may record only one type (say >>> audio) due to its limitations. However an SRS might want to know all >>> the streams of CS. >>> >>> >>> >>> If its required to model these information in metadata, how do we >>> do them ? >>> >>> >>> >>> I would like to get some thoughts/ inputs from interested people in >>> the mailing list on whether there is a value add / need in storing >>> information about streams that are not recorded. >>> >>> >>> >>> Regards, >>> >>> Ram >>> >>> >> _______________________________________________ >> 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 > From Henry.Lum@alcatel-lucent.com Mon Jan 17 08:13:40 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C38C28C0E0 for ; Mon, 17 Jan 2011 08:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.372 X-Spam-Level: X-Spam-Status: No, score=-5.372 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PyIarl5kNzT for ; Mon, 17 Jan 2011 08:13:39 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 387CF28C0DD for ; Mon, 17 Jan 2011 08:13:38 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p0HGGAkC001390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Jan 2011 10:16:11 -0600 (CST) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [172.22.70.114]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0HGG983020290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 17 Jan 2011 10:16:10 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.wc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id p0HGG8kl021111; Mon, 17 Jan 2011 08:16:09 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jan 2011 08:16:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: B/yk D47d E4SM E5q5 GAMf HFDN HQFY KaS7 K4PI Mk02 PGNU Pitl QTPD V1Kv W+n1 X0nX; 3; cABhAHIAdAByAEAAYwBpAHMAYwBvAC4AYwBvAG0AOwBwAGsAeQB6AGkAdgBhAHQAQABjAGkAcwBjAG8ALgBjAG8AbQA7AHMAaQBwAHIAZQBjAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {E37DA5A2-DB01-4E9B-B736-E0F67DEC720E}; aABlAG4AcgB5AC4AbAB1AG0AQABnAGUAbgBlAHMAeQBzAGwAYQBiAC4AYwBvAG0A; Mon, 17 Jan 2011 16:16:02 GMT; UgBFADoAIABbAHMAaQBwAHIAZQBjAF0AIABTAEkAUABSAEUAQwAgAE0AZQB0AGEAZABhAHQAYQAgAG0AbwBkAGUAbAA6ACAASQBzACAAaQB0ACAAcgBlAHEAdQBpAHIAZQBkACAAdABvACAAbQBvAGQAZQBsAAkAcwB0AHIAZQBhAG0AcwAgAHQAaABhAHQAIABhAHIAZQAgAG4AbwB0ACAAcgBlAGMAbwByAGQAZQBkACAAPwA= MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {E37DA5A2-DB01-4E9B-B736-E0F67DEC720E} Content-class: urn:content-classes:message Date: Mon, 17 Jan 2011 08:16:02 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF740690451A@NAHALD.us.int.genesyslab.com> In-Reply-To: <4D3468CD.5030703@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] SIPREC Metadata model: Is it required to model streams that are not recorded ? Thread-Index: Acu2YGXhRYywJ5S9ScCGdX/fSkC+0wAAR/iw References: <35BCE99A477D6A4986FB2216D8CF2CFD04CCB7FC@XMB-BGL-417.cisco.com><4D10C503.9010105@cisco.com> <4D3468CD.5030703@cisco.com> From: "Henry Lum" To: "Paul Kyzivat" , "Parthasarathi R (partr)" X-OriginalArrivalTime: 17 Jan 2011 16:16:08.0808 (UTC) FILETIME=[D98B9E80:01CBB661] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: siprec@ietf.org Subject: Re: [siprec] SIPREC Metadata model: Is it required to model streams that are not recorded ? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 16:13:40 -0000 I think using port 0 would be a better choice than a=3Dinactive since bot= h sides will not need to reserve a port number if it is set to zero, and zero clearly indicates that the stream is no longer used. Regards, Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Monday, January 17, 2011 11:06 AM > To: Parthasarathi R (partr) > Cc: siprec@ietf.org > Subject: Re: [siprec] SIPREC Metadata model: Is it required to model > streams that are not recorded ? >=20 >=20 >=20 > On 1/17/2011 3:47 AM, Parthasarathi R (partr) wrote: > > Paul/John, > > > > IMO, the metadata shall contain rejected or non-recorded m-line > > information and recording session SDP have to carry non-recorded m- > line > > information. > > > > I have another alternative approach in mind to solve this issue in > > Metadata. In case of media stream is not active in CS, Recording > session > > has to carry non-active m-line (port 0 or a=3Dinactive) information > with > > label attribute (RFC 4574) then the external document shall refer to > > m-line using label attribute. SRS shall understand about non-active > > stream by the analysis of SDP metadata. Here, the external document > has > > no need to aware of the stream state. >=20 > This approach seems workable to me. >=20 > Thanks, > Paul >=20 > > Thanks > > Partha > > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > > Of Paul Kyzivat (pkyzivat) > > Sent: Tuesday, December 21, 2010 8:47 PM > > To: siprec@ietf.org > > Subject: Re: [siprec] SIPREC Metadata model: Is it required to model > > streams that are not recorded ? > > > > > > > > On 12/21/2010 8:47 AM, Elwell, John wrote: > >> If additional media streams are offered to the SRS but declined, > > clearly the SRS knows of the existence of those streams. So I think > the > > point behind the question is whether the SRS needs to know the > > subsequent fate of those additional streams in the CS, e.g., if they > are > > held, resumed, disabled, etc.. > > > > One possibility is for the SRC to continue offering them even though > > they have been previously declined. However there is some cost to > doing > > this, in maintaining media ports, possibly using ICE, etc. > > > > An alternative might be to send metadata about these hypothetical > > streams without any cross reference to the SDP. But that will require > > being careful that sufficient info is in the metadata without the SDP > in > > the RS. > > > > Thanks, > > Paul > > > >> John > >> > >> > >>> -----Original Message----- > >>> From: siprec-bounces@ietf.org > >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) > >>> Sent: 21 December 2010 13:29 > >>> To: siprec@ietf.org > >>> Subject: [siprec] SIPREC Metadata model: Is it required to model > >>> streams that are not recorded ? > >>> > >>> Hi all, > >>> > >>> > >>> > >>> During the SIPREC IETF dec 16th 2010 virtual interim we discussed > in > >>> brief about the need to model stream that are not recorded ( there > >>> were people like Leon who have suggested on having this in the > >>> model). > >>> > >>> > >>> > >>> e.g. SRC offered certain media types (like audio, video) but SRS > >>> choose to accept only subset of them ( say only audio). > >>> > >>> The other possibility could be a CS might have multiple media > >>> types(audio, video) but an SRC may record only one type (say > >>> audio) due to its limitations. However an SRS might want to know > all > >>> the streams of CS. > >>> > >>> > >>> > >>> If its required to model these information in metadata, how do we > >>> do them ? > >>> > >>> > >>> > >>> I would like to get some thoughts/ inputs from interested people in > >>> the mailing list on whether there is a value add / need in storing > >>> information about streams that are not recorded. > >>> > >>> > >>> > >>> Regards, > >>> > >>> Ram > >>> > >>> > >> _______________________________________________ > >> 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 =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From john.elwell@siemens-enterprise.com Mon Jan 17 08:23:06 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB5363A6BC1 for ; Mon, 17 Jan 2011 08:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBiAU7aMcWAf for ; Mon, 17 Jan 2011 08:23:04 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 8832E3A6BA3 for ; Mon, 17 Jan 2011 08:23:04 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3034577 for siprec@ietf.org; Mon, 17 Jan 2011 17:25:32 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id CA1DF1EB82B5 for ; Mon, 17 Jan 2011 17:25:22 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 17 Jan 2011 17:25:23 +0100 From: "Elwell, John" To: "siprec@ietf.org" Date: Mon, 17 Jan 2011 17:25:20 +0100 Thread-Topic: WGLC comments on siprec-req-06 Thread-Index: Acu2YyIsRf9CmsUSTiKw4g9xxHZSWA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] WGLC comments on siprec-req-06 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 16:23:06 -0000 My WGLC comments (as individual).=20 I think the document is almost ready to go, but needs the following minor p= oints and nits fixing. Minor: 1. Abstract: "This document specifies requirements for extensions to SIP that will manage delivery of RTP media from an end- point that originates media (or that has access to it) to a recording device." The words "end-point" and "originates" are not really suitable where the SR= C is at a B2BUA. I would suggest rewording as: "This document specifies requirements for extensions to SIP that will manag= e delivery of RTP media to a recording device." 2. Section 3: "An SRS is a logical function that typically archives media for extended durations of time and provides interfaces for search and retrieval of the archived media." I don't think the SRS provides such interfaces. Such interfaces would be av= ailable, but I don't think they should be considered part of the SRS. Also = I don't think the word "typically" is necessary. I would suggest a reword a= s follows: "An SRS is a logical function that archives media for extended periods. Oth= er functions can provide interfaces for searching and retrieving archived m= edia." 3. Section 3: "An SRS is typically implemented as a multi-port device that is capable of receiving media from several sources simultaneously." The word "several" seems to suggest a small number. I would suggest we chan= ge "several" to "multiple". 4. Section 3: "An SRS is typically also the sink of the recorded session metadata." Delete the word "typically" - I don't think we have any other model in mind= . 5. Section 3: "Communication Session (CS): A session created between two or more SIP User Agents (UAs) that is the target for recording." Change "target for recording" to "subject of recording". 6. Section 4: As a general comment, there are several incomplete sentences, e.g.: - Use case 3 "One or more Recording Sessions per Communication Session:" (no verb) - Use case 9 "Record a call that is associated with another call." (no subj= ect) - Use case 12 "Recording and real-time analytics of trading floor interacti= ons (including video and instant messaging)." (no verb) 7. Section 4, use case 4: "or in parallel (Fig. 7)" The figure number is wrong (should be figure 6), but I suggest we delete th= ese words. The subject of parallel CSs is introduced in the paragraph immed= iately preceding figure 6, so we don't need to mention it here. 8. Section 4, use case 4: "A Recording Session records continuously without interruption. Silent periods must be reproduced upon playback (e.g. by recording the silent period, by not recording the silent periods but marking them as metadata for a player to utilize, etc.)" I think the point we are trying to make with use case 4 is that the RS exis= ts even when there is no CS - so it is more than just a silent period. I wo= uld reword as: "A Recording Session records continuously without interruption. Periods whe= n there is no CS in progress must be reproduced upon playback (e.g. by reco= rding silence during such periods or by not recording such periods but mark= ing them by means of metadata for utilization on playback, etc.)." 9. Section 4, use case 4: "The connection and attributes of media in the Recording Session are not dynamically signaled for each Communication Session before it can be recorded; however, codec re-negotiation is possible. CS details and CS metadata will still be signaled, and can be correlated to the recorded media. There will still need to be a means of correlating the recorded media connection/packets to the Communication Session." I think the whole paragraph is getting into solution and could be omitted. 10. Section 4, use case 5: "One solution is to not record a caller speaking their credit card information." Why is not recording just one solution to "not capturing" (in the first sen= tence of the paragraph)? It seems to me it is the ONLY solution. Clearly yo= u could record and then prevent playback, but then you have captured the in= formation. 11. Section 4, use case 7: "Many agents and enterprise workers are not located on company premises." To make it clearer: "Many agents and enterprise workers whose calls are to be recorded are not = located on company premises." 12. Section 4, use case 8: "Internal calls inside or between branches must be recorded." Why do only internal calls need recording? Should it say: "Internal calls inside or between branches must be recorded, as well as cal= ls involving the central office and external calls." 13. Section 4, use case 8: "Global banks with multiple branches up to thousands of small sites. o Only phones and network infrastructure in branches, no recording services. o Internal calls inside or between branches must be recorded. o Centralized recording system in data centers together with telephony infrastructure (e.g. PBX)." The three bullets don't seem to form a coherent set. The first and last des= cribe the topology and the second describes recording needs. 14. Section 4, use case 9: "Record a call that is associated with another call." Apart from the fact this is not a complete sentence (see earlier comment), = I think the point we should be making is that both calls are recorded, toge= ther with some means of associating them. 15. Section 4, use case 10: "o The Communication Session must be terminated (or suitable notification) in the event of a recording failure." Change "or suitable notification" to "or suitable notification given to par= ties". 16. Section 4, use case 11: "In trading floors environments, in order to save resources, it may be preferable to mix multiple concurrent calls (Communication Sessions) on different handsets/speakers on the same turret into single recording session." It is unclear what resources this really saves, unless you also mix the med= ia from the several CSs into a single media stream on the RS. Some clarific= ation would be useful. 17. Section 4, use case 12: "Recorder must support real-time media processing, such as speech analytics." I think this should say "It must be possible for a recorder to support...". Nits: 18. Expand the following acronyms on first use: DTMF, ASR. 19. Section 4, use case 4: "in sequence (Fig. 6)" This should be figure 5. 20. Section 4, use case 4: "The length of a Persistent Recording Sessions " Change "Sessions" to "Session". 21. Section 4, use case 7: "i.e. insurance agents, brokers, physicians." Change "i.e." to "e.g.". 22. Section 4, use case 11: "Media is synchronized" Change "is" to "are". 23. Section 4, use case 12: "(stopping interaction or alert)" Change "alert" to "alerting". John= From john.elwell@siemens-enterprise.com Mon Jan 17 08:30:31 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4583D28C0F1 for ; Mon, 17 Jan 2011 08:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.227 X-Spam-Level: X-Spam-Status: No, score=-102.227 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTWKFkbBpA4T for ; Mon, 17 Jan 2011 08:30:30 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 16F633A6B91 for ; Mon, 17 Jan 2011 08:30:29 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3038179; Mon, 17 Jan 2011 17:33:03 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id CC01E1EB82AB; Mon, 17 Jan 2011 17:33:03 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 17 Jan 2011 17:33:03 +0100 From: "Elwell, John" To: "Parthasarathi R (partr)" , "Paul Kyzivat (pkyzivat)" , "siprec@ietf.org" Date: Mon, 17 Jan 2011 17:33:01 +0100 Thread-Topic: [siprec] SIPREC Metadata model: Is it required to model streams that are not recorded ? Thread-Index: AcuhIjRhcnaoey6VSOmSz8MLyiwQYgU/tvTwABCpP1A= Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD04CCB7FC@XMB-BGL-417.cisco.com> <4D10C503.9010105@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] SIPREC Metadata model: Is it required to model streams that are not recorded ? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 16:30:31 -0000 Partha, Just to be clear what you are proposing. I imagine that in the RS SDP at th= e start of the CS, the SRC supplies an RFC 4574 label for each offered medi= um. Then, even if a particular medium is rejected by the SRS, updates to me= tadata can reference that label to indicate future changes to the correspon= ding medium on the CS. Correct? John > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) > Sent: 17 January 2011 08:47 > To: Paul Kyzivat (pkyzivat); siprec@ietf.org > Subject: Re: [siprec] SIPREC Metadata model: Is it required=20 > to model streams that are not recorded ? >=20 > Paul/John, >=20 > IMO, the metadata shall contain rejected or non-recorded m-line > information and recording session SDP have to carry=20 > non-recorded m-line > information. >=20 > I have another alternative approach in mind to solve this issue in > Metadata. In case of media stream is not active in CS,=20 > Recording session > has to carry non-active m-line (port 0 or a=3Dinactive) information with > label attribute (RFC 4574) then the external document shall refer to > m-line using label attribute. SRS shall understand about non-active > stream by the analysis of SDP metadata. Here, the external=20 > document has > no need to aware of the stream state. >=20 > Thanks > Partha=20 >=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf > Of Paul Kyzivat (pkyzivat) > Sent: Tuesday, December 21, 2010 8:47 PM > To: siprec@ietf.org > Subject: Re: [siprec] SIPREC Metadata model: Is it required to model > streams that are not recorded ? >=20 >=20 >=20 > On 12/21/2010 8:47 AM, Elwell, John wrote: > > If additional media streams are offered to the SRS but declined, > clearly the SRS knows of the existence of those streams. So I=20 > think the > point behind the question is whether the SRS needs to know the > subsequent fate of those additional streams in the CS, e.g.,=20 > if they are > held, resumed, disabled, etc.. >=20 > One possibility is for the SRC to continue offering them even though > they have been previously declined. However there is some=20 > cost to doing > this, in maintaining media ports, possibly using ICE, etc. >=20 > An alternative might be to send metadata about these hypothetical > streams without any cross reference to the SDP. But that will require > being careful that sufficient info is in the metadata without=20 > the SDP in > the RS. >=20 > Thanks, > Paul >=20 > > John > > > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org > >> [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) > >> Sent: 21 December 2010 13:29 > >> To: siprec@ietf.org > >> Subject: [siprec] SIPREC Metadata model: Is it required to model=20 > >> streams that are not recorded ? > >> > >> Hi all, > >> > >> > >> > >> During the SIPREC IETF dec 16th 2010 virtual interim we=20 > discussed in=20 > >> brief about the need to model stream that are not recorded ( there=20 > >> were people like Leon who have suggested on having this in the=20 > >> model). > >> > >> > >> > >> e.g. SRC offered certain media types (like audio, video) but SRS=20 > >> choose to accept only subset of them ( say only audio). > >> > >> The other possibility could be a CS might have multiple media=20 > >> types(audio, video) but an SRC may record only one type (say > >> audio) due to its limitations. However an SRS might want=20 > to know all=20 > >> the streams of CS. > >> > >> > >> > >> If its required to model these information in metadata,=20 > how do we=20 > >> do them ? > >> > >> > >> > >> I would like to get some thoughts/ inputs from interested=20 > people in=20 > >> the mailing list on whether there is a value add / need =20 > in storing=20 > >> information about streams that are not recorded. > >> > >> > >> > >> Regards, > >> > >> Ram > >> > >> > > _______________________________________________ > > 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 > = From andrew.hutton@siemens-enterprise.com Mon Jan 17 09:26:11 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 744C328C1C8 for ; Mon, 17 Jan 2011 09:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSwq5iUrbRuB for ; Mon, 17 Jan 2011 09:26:08 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 869A428C1C4 for ; Mon, 17 Jan 2011 09:26:07 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3035616 for siprec@ietf.org; Mon, 17 Jan 2011 18:28:41 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 6880723F0278 for ; Mon, 17 Jan 2011 18:28:41 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 17 Jan 2011 18:28:41 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Date: Mon, 17 Jan 2011 18:28:43 +0100 Thread-Topic: WGLC comments on siprec-req-06 - AndyH Thread-Index: Acu2a/zhy6Eu2cCcTnKTjGmC9q4ZGw== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E30ABA829449@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] WGLC comments on siprec-req-06 - AndyH X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 17:26:11 -0000 A few WGLC comments on the draft. 1. Abstract: "Recording is typically done by". Maybe could replace "done" w= ith "achieved" or "perfomed". 2. Definitions, 2nd Para":=20 "The SRC itself or another entity working on its behalf (such as a SIP Appl= ication Server) may act as the source of the recording metadata." I believe it is the SRC which is always the source of the metadata. However= of course the SRC could be decomposed in various ways but it is still a co= mponent of the SRC which is the source of metadata. If an SRC receives info= rmation from somewhere else which it uses as metadata then that is also out= of scope. 3. Section 4, Use Case 1:=20 "Use Case 1: Full-time Recording: One (or more, in the case of redundant recording) Recording Session for each Communication Session." There is no other reference to "redundant recording" in the document I thin= k we should therefore remove this statement. I think we agreed that this wa= s just an implementation option and did not need to be a requirement 4. Section 5, Req 10. "REQ-010 The mechanism MUST support the ability to deliver to the SRS multiple media streams for a given CS." Does this refer to the case of multiple media types (E.g. Voice, Video etc.= ) or does it mean multiple media streams of the same type (i.e. one per par= ticipant)? I think we might need to explicitly state a requirement for unm= ixed audio streams from different parties. Regards Andy From pkyzivat@cisco.com Mon Jan 17 10:28:34 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D760628C209 for ; Mon, 17 Jan 2011 10:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.216 X-Spam-Level: X-Spam-Status: No, score=-110.216 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWqxbWOrsbXl for ; Mon, 17 Jan 2011 10:28:33 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 6FB2F28C1CE for ; Mon, 17 Jan 2011 10:28:33 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 17 Jan 2011 18:31:07 +0000 Received: from [10.86.241.224] (che-vpn-cluster-1-479.cisco.com [10.86.241.224]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0HIV6Wh023687; Mon, 17 Jan 2011 18:31:06 GMT Message-ID: <4D348AEA.7040405@cisco.com> Date: Mon, 17 Jan 2011 13:31:06 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Elwell, John" References: <35BCE99A477D6A4986FB2216D8CF2CFD04CCB7FC@XMB-BGL-417.cisco.com> <4D10C503.9010105@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] SIPREC Metadata model: Is it required to model streams that are not recorded ? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 18:28:35 -0000 On 1/17/2011 11:33 AM, Elwell, John wrote: > Partha, > > Just to be clear what you are proposing. I imagine that in the RS SDP at the start of the CS, the SRC supplies an RFC 4574 label for each offered medium. Then, even if a particular medium is rejected by the SRS, updates to metadata can reference that label to indicate future changes to the corresponding medium on the CS. Correct? More than that I think. I'm thinking that as the media stream changes in the CS, that there will need to be another offer on the RS, updating the (rejected) media stream, communicating information such as codec, etc. Maybe that isn't necessary - maybe once the label has been associated with the stream everything else of interest can be communicated as metadata. I guess that remains to determine. It would probably be better if it worked this way. If there is need to offer the stream again, even if it isn't to be recorded, then it requires assigning a port just in case it *might* be accepted. Or maybe we are talking about offering a media stream in the RS with port zero from the start, just so we can attach a label to it. Thanks, Paul > John > >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) >> Sent: 17 January 2011 08:47 >> To: Paul Kyzivat (pkyzivat); siprec@ietf.org >> Subject: Re: [siprec] SIPREC Metadata model: Is it required >> to model streams that are not recorded ? >> >> Paul/John, >> >> IMO, the metadata shall contain rejected or non-recorded m-line >> information and recording session SDP have to carry >> non-recorded m-line >> information. >> >> I have another alternative approach in mind to solve this issue in >> Metadata. In case of media stream is not active in CS, >> Recording session >> has to carry non-active m-line (port 0 or a=inactive) information with >> label attribute (RFC 4574) then the external document shall refer to >> m-line using label attribute. SRS shall understand about non-active >> stream by the analysis of SDP metadata. Here, the external >> document has >> no need to aware of the stream state. >> >> Thanks >> Partha >> >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf >> Of Paul Kyzivat (pkyzivat) >> Sent: Tuesday, December 21, 2010 8:47 PM >> To: siprec@ietf.org >> Subject: Re: [siprec] SIPREC Metadata model: Is it required to model >> streams that are not recorded ? >> >> >> >> On 12/21/2010 8:47 AM, Elwell, John wrote: >>> If additional media streams are offered to the SRS but declined, >> clearly the SRS knows of the existence of those streams. So I >> think the >> point behind the question is whether the SRS needs to know the >> subsequent fate of those additional streams in the CS, e.g., >> if they are >> held, resumed, disabled, etc.. >> >> One possibility is for the SRC to continue offering them even though >> they have been previously declined. However there is some >> cost to doing >> this, in maintaining media ports, possibly using ICE, etc. >> >> An alternative might be to send metadata about these hypothetical >> streams without any cross reference to the SDP. But that will require >> being careful that sufficient info is in the metadata without >> the SDP in >> the RS. >> >> Thanks, >> Paul >> >>> John >>> >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) >>>> Sent: 21 December 2010 13:29 >>>> To: siprec@ietf.org >>>> Subject: [siprec] SIPREC Metadata model: Is it required to model >>>> streams that are not recorded ? >>>> >>>> Hi all, >>>> >>>> >>>> >>>> During the SIPREC IETF dec 16th 2010 virtual interim we >> discussed in >>>> brief about the need to model stream that are not recorded ( there >>>> were people like Leon who have suggested on having this in the >>>> model). >>>> >>>> >>>> >>>> e.g. SRC offered certain media types (like audio, video) but SRS >>>> choose to accept only subset of them ( say only audio). >>>> >>>> The other possibility could be a CS might have multiple media >>>> types(audio, video) but an SRC may record only one type (say >>>> audio) due to its limitations. However an SRS might want >> to know all >>>> the streams of CS. >>>> >>>> >>>> >>>> If its required to model these information in metadata, >> how do we >>>> do them ? >>>> >>>> >>>> >>>> I would like to get some thoughts/ inputs from interested >> people in >>>> the mailing list on whether there is a value add / need >> in storing >>>> information about streams that are not recorded. >>>> >>>> >>>> >>>> Regards, >>>> >>>> Ram >>>> >>>> >>> _______________________________________________ >>> 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 >> From Leon.Portman@nice.com Mon Jan 17 22:43:50 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D04E73A6F7C for ; Mon, 17 Jan 2011 22:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJJMnB6BhrDm for ; Mon, 17 Jan 2011 22:43:46 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id B7C313A6F6D for ; Mon, 17 Jan 2011 22:43:43 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Tue, 18 Jan 2011 08:46:18 +0200 From: Leon Portman To: Paul Kyzivat , "Elwell, John" Date: Tue, 18 Jan 2011 08:46:15 +0200 Thread-Topic: [siprec] SIPREC Metadata model: Is it required to model streams that are not recorded ? Thread-Index: Acu2dLuW4E8V9X5mT9mQAKnKDqhUYgAZje9w Message-ID: <07465C1D981ABC41A344374066AE1A2C389F448716@TLVMBX01.nice.com> References: <35BCE99A477D6A4986FB2216D8CF2CFD04CCB7FC@XMB-BGL-417.cisco.com> <4D10C503.9010105@cisco.com> <4D348AEA.7040405@cisco.com> In-Reply-To: <4D348AEA.7040405@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] SIPREC Metadata model: Is it required to model streams that are not recorded ? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 06:43:50 -0000 Paul, Partha I like the idea to have port=3D0 and media inactive for rejected media stre= ams in order to be able for SRS mid-call start to record these streams as w= ell. Regarding rejected/not recorded media events, I agree that we need to keep = an option for reporting it via metadata events. It will provide most robust= mechanism Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: Monday, January 17, 2011 8:31 PM To: Elwell, John Cc: siprec@ietf.org Subject: Re: [siprec] SIPREC Metadata model: Is it required to model stream= s that are not recorded ? On 1/17/2011 11:33 AM, Elwell, John wrote: > Partha, > > Just to be clear what you are proposing. I imagine that in the RS SDP at = the start of the CS, the SRC supplies an RFC 4574 label for each offered me= dium. Then, even if a particular medium is rejected by the SRS, updates to = metadata can reference that label to indicate future changes to the corresp= onding medium on the CS. Correct? More than that I think. I'm thinking that as the media stream changes in=20 the CS, that there will need to be another offer on the RS, updating the=20 (rejected) media stream, communicating information such as codec, etc. Maybe that isn't necessary - maybe once the label has been associated=20 with the stream everything else of interest can be communicated as=20 metadata. I guess that remains to determine. It would probably be better=20 if it worked this way. If there is need to offer the stream again, even=20 if it isn't to be recorded, then it requires assigning a port just in=20 case it *might* be accepted. Or maybe we are talking about offering a media stream in the RS with=20 port zero from the start, just so we can attach a label to it. Thanks, Paul > John > >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) >> Sent: 17 January 2011 08:47 >> To: Paul Kyzivat (pkyzivat); siprec@ietf.org >> Subject: Re: [siprec] SIPREC Metadata model: Is it required >> to model streams that are not recorded ? >> >> Paul/John, >> >> IMO, the metadata shall contain rejected or non-recorded m-line >> information and recording session SDP have to carry >> non-recorded m-line >> information. >> >> I have another alternative approach in mind to solve this issue in >> Metadata. In case of media stream is not active in CS, >> Recording session >> has to carry non-active m-line (port 0 or a=3Dinactive) information with >> label attribute (RFC 4574) then the external document shall refer to >> m-line using label attribute. SRS shall understand about non-active >> stream by the analysis of SDP metadata. Here, the external >> document has >> no need to aware of the stream state. >> >> Thanks >> Partha >> >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf >> Of Paul Kyzivat (pkyzivat) >> Sent: Tuesday, December 21, 2010 8:47 PM >> To: siprec@ietf.org >> Subject: Re: [siprec] SIPREC Metadata model: Is it required to model >> streams that are not recorded ? >> >> >> >> On 12/21/2010 8:47 AM, Elwell, John wrote: >>> If additional media streams are offered to the SRS but declined, >> clearly the SRS knows of the existence of those streams. So I >> think the >> point behind the question is whether the SRS needs to know the >> subsequent fate of those additional streams in the CS, e.g., >> if they are >> held, resumed, disabled, etc.. >> >> One possibility is for the SRC to continue offering them even though >> they have been previously declined. However there is some >> cost to doing >> this, in maintaining media ports, possibly using ICE, etc. >> >> An alternative might be to send metadata about these hypothetical >> streams without any cross reference to the SDP. But that will require >> being careful that sufficient info is in the metadata without >> the SDP in >> the RS. >> >> Thanks, >> Paul >> >>> John >>> >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) >>>> Sent: 21 December 2010 13:29 >>>> To: siprec@ietf.org >>>> Subject: [siprec] SIPREC Metadata model: Is it required to model >>>> streams that are not recorded ? >>>> >>>> Hi all, >>>> >>>> >>>> >>>> During the SIPREC IETF dec 16th 2010 virtual interim we >> discussed in >>>> brief about the need to model stream that are not recorded ( there >>>> were people like Leon who have suggested on having this in the >>>> model). >>>> >>>> >>>> >>>> e.g. SRC offered certain media types (like audio, video) but SRS >>>> choose to accept only subset of them ( say only audio). >>>> >>>> The other possibility could be a CS might have multiple media >>>> types(audio, video) but an SRC may record only one type (say >>>> audio) due to its limitations. However an SRS might want >> to know all >>>> the streams of CS. >>>> >>>> >>>> >>>> If its required to model these information in metadata, >> how do we >>>> do them ? >>>> >>>> >>>> >>>> I would like to get some thoughts/ inputs from interested >> people in >>>> the mailing list on whether there is a value add / need >> in storing >>>> information about streams that are not recorded. >>>> >>>> >>>> >>>> Regards, >>>> >>>> Ram >>>> >>>> >>> _______________________________________________ >>> 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 >> _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From Leon.Portman@nice.com Mon Jan 17 22:50:20 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E75B23A6F6C for ; Mon, 17 Jan 2011 22:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMjUxDqOoD9O for ; Mon, 17 Jan 2011 22:50:12 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id 3394E3A6F71 for ; Mon, 17 Jan 2011 22:50:11 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Tue, 18 Jan 2011 08:52:42 +0200 From: Leon Portman To: "Hutton, Andrew" , "siprec@ietf.org" Date: Tue, 18 Jan 2011 08:52:40 +0200 Thread-Topic: WGLC comments on siprec-req-06 - AndyH Thread-Index: Acu2a/zhy6Eu2cCcTnKTjGmC9q4ZGwAb5lQg Message-ID: <07465C1D981ABC41A344374066AE1A2C389F44871A@TLVMBX01.nice.com> References: <101C6067BEC68246B0C3F6843BCCC1E30ABA829449@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E30ABA829449@MCHP058A.global-ad.net> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] WGLC comments on siprec-req-06 - AndyH X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 06:50:20 -0000 Andy, Hi Thank you for the comments Please see below Leob -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Hutton, Andrew Sent: Monday, January 17, 2011 7:29 PM To: siprec@ietf.org Subject: [siprec] WGLC comments on siprec-req-06 - AndyH A few WGLC comments on the draft. 1. Abstract: "Recording is typically done by". Maybe could replace "done" w= ith "achieved" or "perfomed". [leon] don't have any strong opinion about it 2. Definitions, 2nd Para":=20 "The SRC itself or another entity working on its behalf (such as a SIP Appl= ication Server) may act as the source of the recording metadata." I believe it is the SRC which is always the source of the metadata. However= of course the SRC could be decomposed in various ways but it is still a co= mponent of the SRC which is the source of metadata. If an SRC receives info= rmation from somewhere else which it uses as metadata then that is also out= of scope. [leon] I don't think that we should limit scope in such way. Why do we care= if SRC received metadata from some other entity, like CTI server for backw= ard compatibility case? =20 3. Section 4, Use Case 1:=20 "Use Case 1: Full-time Recording: One (or more, in the case of redundant recording) Recording Session for each Communication Session." There is no other reference to "redundant recording" in the document I thin= k we should therefore remove this statement. I think we agreed that this wa= s just an implementation option and did not need to be a requirement [leon] May be "duplicate" will be a better term? It is just an example, and= not actual requirement 4. Section 5, Req 10. "REQ-010 The mechanism MUST support the ability to deliver to the SRS multiple media streams for a given CS." Does this refer to the case of multiple media types (E.g. Voice, Video etc.= ) or does it mean multiple media streams of the same type (i.e. one per par= ticipant)? I think we might need to explicitly state a requirement for unm= ixed audio streams from different parties. [leon] Yes, it means actually both. It is obvious for different types and n= ot so obvious for unmixed streams Regards Andy _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From Leon.Portman@nice.com Mon Jan 17 23:07:37 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B9E43A6FAB for ; Mon, 17 Jan 2011 23:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1z93y7lafYB for ; Mon, 17 Jan 2011 23:07:34 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id B59793A6FA2 for ; Mon, 17 Jan 2011 23:07:32 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Tue, 18 Jan 2011 09:10:08 +0200 From: Leon Portman To: "Elwell, John" , "siprec@ietf.org" , "Ken Rehor (krehor)" Date: Tue, 18 Jan 2011 09:10:06 +0200 Thread-Topic: WGLC comments on siprec-req-06 Thread-Index: Acu2YyIsRf9CmsUSTiKw4g9xxHZSWAAeTJ5w Message-ID: <07465C1D981ABC41A344374066AE1A2C389F448727@TLVMBX01.nice.com> References: In-Reply-To: Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] WGLC comments on siprec-req-06 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 07:07:37 -0000 John, Hello Thank you for the very thorough comments Please see below Ken, what do you think? Thanks Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Elwell, John Sent: Monday, January 17, 2011 6:25 PM To: siprec@ietf.org Subject: [siprec] WGLC comments on siprec-req-06 My WGLC comments (as individual).=20 I think the document is almost ready to go, but needs the following minor p= oints and nits fixing. Minor: 1. Abstract: "This document specifies requirements for extensions to SIP that will manage delivery of RTP media from an end- point that originates media (or that has access to it) to a recording device." The words "end-point" and "originates" are not really suitable where the SR= C is at a B2BUA. I would suggest rewording as: "This document specifies requirements for extensions to SIP that will manag= e delivery of RTP media to a recording device." [leon] Ok 2. Section 3: "An SRS is a logical function that typically archives media for extended durations of time and provides interfaces for search and retrieval of the archived media." I don't think the SRS provides such interfaces. Such interfaces would be av= ailable, but I don't think they should be considered part of the SRS. Also = I don't think the word "typically" is necessary. I would suggest a reword a= s follows: "An SRS is a logical function that archives media for extended periods. Oth= er functions can provide interfaces for searching and retrieving archived m= edia." [leon] Ok 3. Section 3: "An SRS is typically implemented as a multi-port device that is capable of receiving media from several sources simultaneously." The word "several" seems to suggest a small number. I would suggest we chan= ge "several" to "multiple". [leon] Ok 4. Section 3: "An SRS is typically also the sink of the recorded session metadata." Delete the word "typically" - I don't think we have any other model in mind= . [leon] ok, however there can be other sinks as well for the metadata (if we= talking about dedicated metadata subscription session) 5. Section 3: "Communication Session (CS): A session created between two or more SIP User Agents (UAs) that is the target for recording." Change "target for recording" to "subject of recording". [leon] Ok, however recording target is a common term for some SRS vendors (= not us however) 6. Section 4: As a general comment, there are several incomplete sentences, e.g.: - Use case 3 "One or more Recording Sessions per Communication Session:" (no verb) - Use case 9 "Record a call that is associated with another call." (no subj= ect) - Use case 12 "Recording and real-time analytics of trading floor interacti= ons (including video and instant messaging)." (no verb) [leon] Ok, how about following: Use case 3: One or more Recording Sessions performed per Communication Sess= ion Use case 9: Cradle to grave recording: Record a call that is associated wit= h another call Use Case 12: execution of Recording and real-time analytics of trading floo= r interactions (including video and instant messaging) 7. Section 4, use case 4: "or in parallel (Fig. 7)" The figure number is wrong (should be figure 6), but I suggest we delete th= ese words. The subject of parallel CSs is introduced in the paragraph immed= iately preceding figure 6, so we don't need to mention it here. [leon] Ok 8. Section 4, use case 4: "A Recording Session records continuously without interruption. Silent periods must be reproduced upon playback (e.g. by recording the silent period, by not recording the silent periods but marking them as metadata for a player to utilize, etc.)" I think the point we are trying to make with use case 4 is that the RS exis= ts even when there is no CS - so it is more than just a silent period. I wo= uld reword as: "A Recording Session records continuously without interruption. Periods whe= n there is no CS in progress must be reproduced upon playback (e.g. by reco= rding silence during such periods or by not recording such periods but mark= ing them by means of metadata for utilization on playback, etc.)." [Leon] we have actually two use cases here, silence during CS and between C= Ss. Between CSs is easy, because SRS will know that there is no call in pro= gress. However if there is a silence during the call and no silence suppres= sion in the original media stream, SRS will not know if it just loose packe= ts or SRS should report silence periods either via silence suppression or m= etadata 9. Section 4, use case 4: "The connection and attributes of media in the Recording Session are not dynamically signaled for each Communication Session before it can be recorded; however, codec re-negotiation is possible. CS details and CS metadata will still be signaled, and can be correlated to the recorded media. There will still need to be a means of correlating the recorded media connection/packets to the Communication Session." I think the whole paragraph is getting into solution and could be omitted. [leon] what we tried to demonstrate here is the challenge of correlation be= tween CS and metadata. I am ok to remove it, however it is just example 10. Section 4, use case 5: "One solution is to not record a caller speaking their credit card information." Why is not recording just one solution to "not capturing" (in the first sen= tence of the paragraph)? It seems to me it is the ONLY solution. Clearly yo= u could record and then prevent playback, but then you have captured the in= formation. [leon] it depends on the business scenario. For some use cases playback is = allowed for specific persons in the organization. 11. Section 4, use case 7: "Many agents and enterprise workers are not located on company premises." To make it clearer: "Many agents and enterprise workers whose calls are to be recorded are not = located on company premises." [Leon] Ok 12. Section 4, use case 8: "Internal calls inside or between branches must be recorded." Why do only internal calls need recording? Should it say: "Internal calls inside or between branches must be recorded, as well as cal= ls involving the central office and external calls." [Leon] Yes 13. Section 4, use case 8: "Global banks with multiple branches up to thousands of small sites. o Only phones and network infrastructure in branches, no recording services. o Internal calls inside or between branches must be recorded. o Centralized recording system in data centers together with telephony infrastructure (e.g. PBX)." The three bullets don't seem to form a coherent set. The first and last des= cribe the topology and the second describes recording needs. [leon] how about swapping 2 and 3? 14. Section 4, use case 9: "Record a call that is associated with another call." Apart from the fact this is not a complete sentence (see earlier comment), = I think the point we should be making is that both calls are recorded, toge= ther with some means of associating them. [leon] yes, correct 15. Section 4, use case 10: "o The Communication Session must be terminated (or suitable notification) in the event of a recording failure." Change "or suitable notification" to "or suitable notification given to par= ties". [leon] ok 16. Section 4, use case 11: "In trading floors environments, in order to save resources, it may be preferable to mix multiple concurrent calls (Communication Sessions) on different handsets/speakers on the same turret into single recording session." It is unclear what resources this really saves, unless you also mix the med= ia from the several CSs into a single media stream on the RS. Some clarific= ation would be useful. [leon] it saves recording channels by mixing multiple CSs into the same rec= ording channel 17. Section 4, use case 12: "Recorder must support real-time media processing, such as speech analytics." I think this should say "It must be possible for a recorder to support...". [leon] Ok Nits: 18. Expand the following acronyms on first use: DTMF, ASR. [Leon] Ok 19. Section 4, use case 4: "in sequence (Fig. 6)" This should be figure 5. [leon] ok 20. Section 4, use case 4: "The length of a Persistent Recording Sessions " Change "Sessions" to "Session". [leon] Ok 21. Section 4, use case 7: "i.e. insurance agents, brokers, physicians." Change "i.e." to "e.g.". [leon] ok 22. Section 4, use case 11: "Media is synchronized" Change "is" to "are". [leon] ok 23. Section 4, use case 12: "(stopping interaction or alert)" Change "alert" to "alerting". [leon] ok John _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From Leon.Portman@nice.com Mon Jan 17 23:10:41 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 380FF3A6F99 for ; Mon, 17 Jan 2011 23:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+TfHQYvTETs for ; Mon, 17 Jan 2011 23:10:39 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id C141F3A6FA9 for ; Mon, 17 Jan 2011 23:10:38 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Tue, 18 Jan 2011 09:13:14 +0200 From: Leon Portman To: "Parthasarathi R (partr)" , "Elwell, John" , "siprec@ietf.org" Date: Tue, 18 Jan 2011 09:13:12 +0200 Thread-Topic: [siprec] Inputs to draft-ietf-siprec-req-06 Thread-Index: AcuyUfJnU/vECby9TGaM0uRbXItGhAC8g4WgABTj8SAAIgSUIAAANi2wAADxo7AABC4GcAAGsDKwACPaoVA= Message-ID: <07465C1D981ABC41A344374066AE1A2C389F44872A@TLVMBX01.nice.com> References: In-Reply-To: Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Dave Smith Subject: Re: [siprec] Inputs to draft-ietf-siprec-req-06 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 07:10:41 -0000 Looking good Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Parthasarathi R (partr) Sent: Monday, January 17, 2011 4:35 PM To: Elwell, John; siprec@ietf.org Cc: Dave Smith Subject: Re: [siprec] Inputs to draft-ietf-siprec-req-06 John/David, I'm fine with REQ-5 as long as the intention is to avoid initial clipping in recording using persistent RS or similar SIPREC proposed mechanism. Just, I'm trying to reword for this requirement: o REQ-005 The mechanism MUST support the ability to record a CS without loss of media (for example, clipping media at the beginning of the CS) due to RS recording preparation and also, without impacting the quality or timing of the CS (for example, delaying the start of the CS while preparation for recording session). See Use Case 4 in Section 4 for more details.=20 --- Removed: "intentional" --- Added: "due to RS recording preparation and also" Please let me know your opinion. Thanks Partha -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Monday, January 17, 2011 4:31 PM To: Parthasarathi R (partr); siprec@ietf.org Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06 =20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 17 January 2011 09:09 > To: Elwell, John; siprec@ietf.org > Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06 >=20 > Please read inline >=20 > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Monday, January 17, 2011 2:08 PM > To: Elwell, John; siprec@ietf.org > Subject: Re: [siprec] Inputs to draft-ietf-siprec-req-06 >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: 17 January 2011 08:23 > > To: siprec@ietf.org > > Subject: [siprec] FW: Inputs to draft-ietf-siprec-req-06 > >=20 > > Forwarded on behalf of Dave Smith. > >=20 > > > -----Original Message----- > > > From: Dave Smith [mailto:Dave.Smith@genesyslab.com] > > > Sent: 16 January 2011 16:08 > > > To: Elwell, John > > > Subject: FW: Inputs to draft-ietf-siprec-req-06 > > >=20 > > > Hi John, > > >=20 > > > Can you please send this email out to the "siprec@ietf.org" email=20 > > > address for me. > > > Our Genesys email server is failing to send emails out to > > that address > > > again (in the mean time I will try to get it fixed through our=20 > > > HelpDesk). > > >=20 > > > Thanks, > > > Dave > > >=20 > > >=20 > > > -----Original Message----- > > > From: Dave Smith > > > Sent: Saturday, January 15, 2011 10:59 PM > > > To: Elwell, John; siprec@ietf.org > > > Subject: Inputs to draft-ietf-siprec-req-06 > > >=20 > > > Here are my inputs to the latest draft-ietf-siprec-req-06. =20 > > >=20 > > >=20 > > > 1. Recommend to change this: > > > o REQ-005 The mechanism MUST support the ability to record a CS > > > without an intentional loss of media (for example,=20 > clipping media >=20 > > > at > > > the beginning of the CS) and without impacting the quality or=20 > > > timing > > > of the CS (for example, delaying the start of the CS while > > > preparation for recording takes place). See Use Case 4 in=20 > > > Section 5. > > >=20 > > > To this: > > > o REQ-005 The mechanism MUST support the ability to record a CS > > > without an unintentional loss of media (for example, > > clipping media > > > at > > > the beginning of the CS) and without impacting the quality or=20 > > > timing > > > of the CS (for example, delaying the start of the CS while > > > preparation for recording takes place). =20 > > >=20 > > > The use case is not referenced correctly and I don't see > > any reason to > > > refer to it (doesn't provide much additional info). Also=20 > corrected=20 > > > "intentional" to "unintentional." > [JRE] The word "intentional" came from me a few months ago. Perhaps it > was the wrong word - I was trying to convey the fact that=20 > some mechanism > might frequently lead to clipping - the loss of media is kind of built > into the mechanism, so in that sense it would be=20 > "intentional". I don't > think changing to "unintentional" is correct - we can't avoid > unintentional loss of media, e.g., through packet loss. I=20 > guess what we > are really trying to achieve is something like this: "The=20 > mechanism MUST > support the ability to record a CS without loss of media while > preparation for recording takes place." >=20 > IMO, without any loss of media may lead to inefficient system > in few deployment. For example, CS dialog is established whereas RS is > taking more time to establish due to network delay between=20 > SRC and SRS, > then it may be preferred in few deployment to loss some media=20 > instead of > delaying CS establishment and some other deployment may prefer to wait > for RS establishment. The current requirement wording=20 > indicates that CS > dialog establishment MUST be delayed for RS establishment. =20 [JRE] No, I believe it was not intended to force the CS to be delayed. A mechanism that would meet this requirement without delaying CS establishment would be to keep an RS permanently established, even when there is no CS, so that it can immediately be used when a new CS starts. This was the persistent recording use case (4), which I believe some people felt was needed for some environments, and hence the desire to capture requirements that such environments have. Clearly we have failed to capture that requirements adequately - we need the right words. John (as individual) >=20 > > >=20 > > >=20 > > > 2. Recommend to change this: > > > o REQ-018 The mechanism MUST provide a means of=20 > indicating to the > > > participants involved in a CS that their session is > > being recorded. > > >=20 > > > Examples include: inject tones into the CS from the SRC, play a > > > message at the beginning of a session, a visual indicator on a > > > display, etc. > > >=20 > > > To this: > > > o REQ-018 The mechanism MUST provide a means of=20 > indicating to the > > > participants involved in a CS that their session is > > currently being > > > recorded. > > >=20 > > > Examples include: inject tones into the CS from the=20 > SRC, a visual >=20 > > > indicator on a display > > >=20 > > > Added word "currently" because this is about providing an ongoing=20 > > > indicator during the call. Removed the "play a message...." part=20 > > > because playing a message at the beginning of a session is not a=20 > > > method that would require a siprec protocol solution,=20 > it's n/a, it's >=20 > > > not about " an ongoing indicator." > [JRE] The word "currently" was there, in my opinion, because playing a > message to indicate that recording might take place at some=20 > stage during > the CS is what frequently happens and is sufficient for regulatory > purposes in some jurisdictions. I agree it would not require a SIPREC > protocol solution. Let's see what others say. > I agree with John that playing a message meet some of the > Jurisdictions requirement. I like to hear from Dave whether any > jurisdiction mandates for "injection tone" or "visual display". > >=20 > Thanks > Partha >=20 > John (as individual) >=20 > > >=20 > > >=20 > > > 3. Recommend to change this: > > > o REQ-013 The mechanism MUST provide the SRS with the means to > > > correlate RS media with CS participant media described > > in metadata. > > >=20 > > > To this: > > > o REQ-013 The mechanism MUST provide the SRS with the means to > > > correlate RS media with CS participant media. > > >=20 > > > This is recommended because I don't see the need for the=20 > part that=20 > > > read "described in metadata" and because it is not clear what it=20 > > > meant. > > >=20 > > >=20 > > > 4. Recommend to delete this Requirement: > > > o REQ-021 The mechanism MUST support means to relate Recording > > > Session(s) with Communication Session(s). > > >=20 > > > It is not needed since we have REQ-012 and REQ-013. =20 > > >=20 > > >=20 > > >=20 > > > Regards, > > > Dave > > >=20 > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > > Sent: Wednesday, January 12, 2011 4:12 AM > > > To: siprec@ietf.org > > > Subject: [siprec] Agenda requests plus reminder > > >=20 > > > Please let me have your agenda requests for the dual interim on=20 > > > 25th/26th. > > >=20 > > > Also, a reminder that WGLC on siprec-req is into its second > > week and I > > > have not seen any responses yet. Even if you are happy with it as=20 > > > is, a note to the list would be helpful. > > >=20 > > > John > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > >=20 > > > =09 > > > -------------------------------------------------------------- > > > ---------- > > > ------------------------------------------- > > > CONFIDENTIALITY NOTICE: This e-mail and any files attached > > may contain > > > confidential and proprietary information of Alcatel-Lucent > > and/or its > > > affiliated entities. Access by the intended recipient only is=20 > > > authorized. Any liability arising from any party acting, or > > refraining > > > from acting, on any information contained in this e-mail=20 > is hereby=20 > > > excluded. If you are not the intended recipient, please=20 > notify the=20 > > > sender immediately, destroy the original transmission and its=20 > > > attachments and do not disclose the contents to any other person,=20 > > > use it for any purpose, or store or copy the information in any=20 > > > medium. > > > Copyright in this e-mail and any attachments belongs to > > Alcatel-Lucent > > > and/or its affiliated entities. > > > =09 > > >=20 > > > =09 > > > -------------------------------------------------------------- > > > ----------------------------------------------------- > > > CONFIDENTIALITY NOTICE: This e-mail and any files attached may=20 > > > contain confidential and proprietary information of=20 > Alcatel-Lucent=20 > > > and/or its affiliated entities. Access by the intended recipient=20 > > > only is authorized. Any liability arising from any party=20 > acting, or=20 > > > refraining from acting, on any information contained in=20 > this e-mail=20 > > > is hereby excluded. If you are not the intended recipient, please=20 > > > notify the sender immediately, destroy the original=20 > transmission and >=20 > > > its attachments and do not disclose the contents to any other=20 > > > person, use it for any purpose, or store or copy the=20 > information in=20 > > > any medium. Copyright in this e-mail and any attachments=20 > belongs to=20 > > > Alcatel-Lucent and/or its affiliated > > entities. > > > =09 > > >=20 > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >=20 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Tue Jan 18 05:36:11 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 195CD3A6FDA for ; Tue, 18 Jan 2011 05:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.186 X-Spam-Level: X-Spam-Status: No, score=-10.186 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwzF08m2nW9J for ; Tue, 18 Jan 2011 05:36:09 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id BDE173A6FB6 for ; Tue, 18 Jan 2011 05:36:09 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAA8mNU1AaMHG/2dsb2JhbACkWXOoI5l0hVAEhG2JWw Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-3.cisco.com with ESMTP; 18 Jan 2011 13:38:46 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0IDcijZ002801; Tue, 18 Jan 2011 13:38:45 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Jan 2011 19:08:44 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: cro= B+rO DonF EJCq GQus HAA2 KrEF Kwhg MY5a M7ci P2qC QP7+ Q/mc RuxE SbLo Tidu; 2; agBvAGgAbgAuAGUAbAB3AGUAbABsAEAAcwBpAGUAbQBlAG4AcwAtAGUAbgB0AGUAcgBwAHIAaQBzAGUALgBjAG8AbQA7AHMAaQBwAHIAZQBjAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {86821BEA-5BE4-43AE-B101-5F7DC895645C}; cgBtAG8AaABhAG4AcgBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Tue, 18 Jan 2011 13:38:36 GMT; UgBFADoAIABbAHMAaQBwAHIAZQBjAF0AIABTAEkAUABSAEUAQwAgAE0AZQB0AGEAZABhAHQAYQAgAG0AbwBkAGUAbAA6ACAASQBzACAAaQB0ACAAcgBlAHEAdQBpAHIAZQBkACAAdABvACAAbQBvAGQAZQBsAAkAcwB0AHIAZQBhAG0AcwAgAHQAaABhAHQAIABhAHIAZQAgAG4AbwB0ACAAcgBlAGMAbwByAGQAZQBkACAAPwA= x-cr-puzzleid: {86821BEA-5BE4-43AE-B101-5F7DC895645C} Content-class: urn:content-classes:message Date: Tue, 18 Jan 2011 19:08:35 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD050247CD@XMB-BGL-417.cisco.com> In-Reply-To: <4D348AEA.7040405@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] SIPREC Metadata model: Is it required to model streams that are not recorded ? Thread-Index: Acu2dMPIiGyybtrUSoOXr4BwtIjQCgAnkGOg References: <35BCE99A477D6A4986FB2216D8CF2CFD04CCB7FC@XMB-BGL-417.cisco.com> <4D10C503.9010105@cisco.com> <4D348AEA.7040405@cisco.com> From: "Ram Mohan R (rmohanr)" To: "Paul Kyzivat (pkyzivat)" , "Elwell, John" X-OriginalArrivalTime: 18 Jan 2011 13:38:44.0172 (UTC) FILETIME=[068448C0:01CBB715] Cc: siprec@ietf.org Subject: Re: [siprec] SIPREC Metadata model: Is it required to model streams that are not recorded ? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 13:36:11 -0000 John/ Paul, Please see inline for some comments=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat (pkyzivat) > Sent: Tuesday, January 18, 2011 12:01 AM > To: Elwell, John > Cc: siprec@ietf.org > Subject: Re: [siprec] SIPREC Metadata model: Is it required to model > streams that are not recorded ? >=20 >=20 >=20 > On 1/17/2011 11:33 AM, Elwell, John wrote: > > Partha, > > > > Just to be clear what you are proposing. I imagine that in the RS SDP > at the start of the CS, the SRC supplies an RFC 4574 label for each > offered medium. Then, even if a particular medium is rejected by the > SRS, updates to metadata can reference that label to indicate future > changes to the corresponding medium on the CS. Correct? >=20 > More than that I think. I'm thinking that as the media stream changes > in > the CS, that there will need to be another offer on the RS, updating > the > (rejected) media stream, communicating information such as codec, etc. My thought for this case is to have a SRC offer a stream (that it can record) at the start of RS ( with a valid port) and continue to keep sending updates for that media stream even if the SRS has rejected the stream at the beginning. From the discussions I had in the last interim and before, it is my understanding that SRS would like to know the changes to a media stream even if they are not being recorded after being offered by SRC. My preference would be send the further updates of that media stream ( rejected) through m-line instead of metadata and just having reference to the label in metadata document. The negative side to it would be the cost in keeping the port open [ for the rejected media stream]. >=20 > Maybe that isn't necessary - maybe once the label has been associated > with the stream everything else of interest can be communicated as > metadata. I guess that remains to determine. It would probably be > better > if it worked this way. If there is need to offer the stream again, even > if it isn't to be recorded, then it requires assigning a port just in > case it *might* be accepted. >=20 > Or maybe we are talking about offering a media stream in the RS with > port zero from the start, just so we can attach a label to it. There was another requirement too here if I remember which is for the SRS to know the streams that are part of CS but which are not offered by SRC to SRS. This could be possible if SRC does not have the capability to fork certain media types. In those cases I think we could follow the above approach you mentioned where in SRC can offer a media stream with port zero at the start of CS. After that SRC can keep sending the updates of the same media stream through metadata. Thanks, Ram >=20 > Thanks, > Paul >=20 > > John > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org > >> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R > (partr) > >> Sent: 17 January 2011 08:47 > >> To: Paul Kyzivat (pkyzivat); siprec@ietf.org > >> Subject: Re: [siprec] SIPREC Metadata model: Is it required > >> to model streams that are not recorded ? > >> > >> Paul/John, > >> > >> IMO, the metadata shall contain rejected or non-recorded m-line > >> information and recording session SDP have to carry > >> non-recorded m-line > >> information. > >> > >> I have another alternative approach in mind to solve this issue in > >> Metadata. In case of media stream is not active in CS, > >> Recording session > >> has to carry non-active m-line (port 0 or a=3Dinactive) information > with > >> label attribute (RFC 4574) then the external document shall refer to > >> m-line using label attribute. SRS shall understand about non-active > >> stream by the analysis of SDP metadata. Here, the external > >> document has > >> no need to aware of the stream state. > >> > >> Thanks > >> Partha > >> > >> -----Original Message----- > >> From: siprec-bounces@ietf.org > >> [mailto:siprec-bounces@ietf.org] On Behalf > >> Of Paul Kyzivat (pkyzivat) > >> Sent: Tuesday, December 21, 2010 8:47 PM > >> To: siprec@ietf.org > >> Subject: Re: [siprec] SIPREC Metadata model: Is it required to model > >> streams that are not recorded ? > >> > >> > >> > >> On 12/21/2010 8:47 AM, Elwell, John wrote: > >>> If additional media streams are offered to the SRS but declined, > >> clearly the SRS knows of the existence of those streams. So I > >> think the > >> point behind the question is whether the SRS needs to know the > >> subsequent fate of those additional streams in the CS, e.g., > >> if they are > >> held, resumed, disabled, etc.. > >> > >> One possibility is for the SRC to continue offering them even though > >> they have been previously declined. However there is some > >> cost to doing > >> this, in maintaining media ports, possibly using ICE, etc. > >> > >> An alternative might be to send metadata about these hypothetical > >> streams without any cross reference to the SDP. But that will > require > >> being careful that sufficient info is in the metadata without > >> the SDP in > >> the RS. > >> > >> Thanks, > >> Paul > >> > >>> John > >>> > >>> > >>>> -----Original Message----- > >>>> From: siprec-bounces@ietf.org > >>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R > (rmohanr) > >>>> Sent: 21 December 2010 13:29 > >>>> To: siprec@ietf.org > >>>> Subject: [siprec] SIPREC Metadata model: Is it required to model > >>>> streams that are not recorded ? > >>>> > >>>> Hi all, > >>>> > >>>> > >>>> > >>>> During the SIPREC IETF dec 16th 2010 virtual interim we > >> discussed in > >>>> brief about the need to model stream that are not recorded ( there > >>>> were people like Leon who have suggested on having this in the > >>>> model). > >>>> > >>>> > >>>> > >>>> e.g. SRC offered certain media types (like audio, video) but SRS > >>>> choose to accept only subset of them ( say only audio). > >>>> > >>>> The other possibility could be a CS might have multiple media > >>>> types(audio, video) but an SRC may record only one type (say > >>>> audio) due to its limitations. However an SRS might want > >> to know all > >>>> the streams of CS. > >>>> > >>>> > >>>> > >>>> If its required to model these information in metadata, > >> how do we > >>>> do them ? > >>>> > >>>> > >>>> > >>>> I would like to get some thoughts/ inputs from interested > >> people in > >>>> the mailing list on whether there is a value add / need > >> in storing > >>>> information about streams that are not recorded. > >>>> > >>>> > >>>> > >>>> Regards, > >>>> > >>>> Ram > >>>> > >>>> > >>> _______________________________________________ > >>> 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 > >> > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@cisco.com Tue Jan 18 06:33:56 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D15F28C119 for ; Tue, 18 Jan 2011 06:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.489 X-Spam-Level: X-Spam-Status: No, score=-110.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWY22FYQVUoZ for ; Tue, 18 Jan 2011 06:33:54 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5FB9928C117 for ; Tue, 18 Jan 2011 06:33:54 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 18 Jan 2011 14:36:31 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0IEaVgl004590; Tue, 18 Jan 2011 14:36:31 GMT Message-ID: <4D35A56F.6030500@cisco.com> Date: Tue, 18 Jan 2011 09:36:31 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Ram Mohan R (rmohanr)" References: <35BCE99A477D6A4986FB2216D8CF2CFD04CCB7FC@XMB-BGL-417.cisco.com> <4D10C503.9010105@cisco.com> <4D348AEA.7040405@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD050247CD@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD050247CD@XMB-BGL-417.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] SIPREC Metadata model: Is it required to model streams that are not recorded ? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 14:33:56 -0000 We have to be careful about attaching much significance to m-lines with the port set to zero. Often there is an expectation that once the port is set to zero, none of the other information has meaning. This is especially true when media streams are refused by an answerer that doesn't understand. (This has also come up in draft-ietf-mmusic-image-attributes, but only tangentially.) The situation here in the RS is quite controlled - its between a pair of UAs that will both be bound by the siprec spec, so we may be able to spell out more meaning to rejected streams. But it is something to keep in mind and seek some help from mmusic on. Thanks, Paul On 1/18/2011 8:38 AM, Ram Mohan R (rmohanr) wrote: > John/ Paul, > > Please see inline for some comments > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Paul Kyzivat (pkyzivat) >> Sent: Tuesday, January 18, 2011 12:01 AM >> To: Elwell, John >> Cc: siprec@ietf.org >> Subject: Re: [siprec] SIPREC Metadata model: Is it required to model >> streams that are not recorded ? >> >> >> >> On 1/17/2011 11:33 AM, Elwell, John wrote: >>> Partha, >>> >>> Just to be clear what you are proposing. I imagine that in the RS > SDP >> at the start of the CS, the SRC supplies an RFC 4574 label for each >> offered medium. Then, even if a particular medium is rejected by the >> SRS, updates to metadata can reference that label to indicate future >> changes to the corresponding medium on the CS. Correct? >> >> More than that I think. I'm thinking that as the media stream changes >> in >> the CS, that there will need to be another offer on the RS, updating >> the >> (rejected) media stream, communicating information such as codec, etc. > > My thought for this case is to have a SRC offer a stream (that it can > record) at the start of RS ( with a valid port) and continue to keep > sending updates for that media stream even if the SRS has rejected the > stream at the beginning. From the discussions I had in the last interim > and before, it is my understanding that SRS would like to know the > changes to a media stream even if they are not being recorded after > being offered by SRC. My preference would be send the further updates of > that media stream ( rejected) through m-line instead of metadata and > just having reference to the label in metadata document. > The negative side to it would be the cost in keeping the port open [ for > the rejected media stream]. > >> >> Maybe that isn't necessary - maybe once the label has been associated >> with the stream everything else of interest can be communicated as >> metadata. I guess that remains to determine. It would probably be >> better >> if it worked this way. If there is need to offer the stream again, > even >> if it isn't to be recorded, then it requires assigning a port just in >> case it *might* be accepted. >> >> Or maybe we are talking about offering a media stream in the RS with >> port zero from the start, just so we can attach a label to it. > > There was another requirement too here if I remember which is for the > SRS to know the streams that are part of CS but which are not offered by > SRC to SRS. This could be possible if SRC does not have the capability > to fork certain media types. In those cases I think we could follow the > above approach you mentioned where in SRC can offer a media stream with > port zero at the start of CS. > After that SRC can keep sending the updates of the same media stream > through metadata. > > Thanks, > Ram > >> >> Thanks, >> Paul >> >>> John >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R >> (partr) >>>> Sent: 17 January 2011 08:47 >>>> To: Paul Kyzivat (pkyzivat); siprec@ietf.org >>>> Subject: Re: [siprec] SIPREC Metadata model: Is it required >>>> to model streams that are not recorded ? >>>> >>>> Paul/John, >>>> >>>> IMO, the metadata shall contain rejected or non-recorded m-line >>>> information and recording session SDP have to carry >>>> non-recorded m-line >>>> information. >>>> >>>> I have another alternative approach in mind to solve this issue in >>>> Metadata. In case of media stream is not active in CS, >>>> Recording session >>>> has to carry non-active m-line (port 0 or a=inactive) information >> with >>>> label attribute (RFC 4574) then the external document shall refer > to >>>> m-line using label attribute. SRS shall understand about non-active >>>> stream by the analysis of SDP metadata. Here, the external >>>> document has >>>> no need to aware of the stream state. >>>> >>>> Thanks >>>> Partha >>>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] On Behalf >>>> Of Paul Kyzivat (pkyzivat) >>>> Sent: Tuesday, December 21, 2010 8:47 PM >>>> To: siprec@ietf.org >>>> Subject: Re: [siprec] SIPREC Metadata model: Is it required to > model >>>> streams that are not recorded ? >>>> >>>> >>>> >>>> On 12/21/2010 8:47 AM, Elwell, John wrote: >>>>> If additional media streams are offered to the SRS but declined, >>>> clearly the SRS knows of the existence of those streams. So I >>>> think the >>>> point behind the question is whether the SRS needs to know the >>>> subsequent fate of those additional streams in the CS, e.g., >>>> if they are >>>> held, resumed, disabled, etc.. >>>> >>>> One possibility is for the SRC to continue offering them even > though >>>> they have been previously declined. However there is some >>>> cost to doing >>>> this, in maintaining media ports, possibly using ICE, etc. >>>> >>>> An alternative might be to send metadata about these hypothetical >>>> streams without any cross reference to the SDP. But that will >> require >>>> being careful that sufficient info is in the metadata without >>>> the SDP in >>>> the RS. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> John >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org >>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R >> (rmohanr) >>>>>> Sent: 21 December 2010 13:29 >>>>>> To: siprec@ietf.org >>>>>> Subject: [siprec] SIPREC Metadata model: Is it required to model >>>>>> streams that are not recorded ? >>>>>> >>>>>> Hi all, >>>>>> >>>>>> >>>>>> >>>>>> During the SIPREC IETF dec 16th 2010 virtual interim we >>>> discussed in >>>>>> brief about the need to model stream that are not recorded ( > there >>>>>> were people like Leon who have suggested on having this in the >>>>>> model). >>>>>> >>>>>> >>>>>> >>>>>> e.g. SRC offered certain media types (like audio, video) but SRS >>>>>> choose to accept only subset of them ( say only audio). >>>>>> >>>>>> The other possibility could be a CS might have multiple media >>>>>> types(audio, video) but an SRC may record only one type (say >>>>>> audio) due to its limitations. However an SRS might want >>>> to know all >>>>>> the streams of CS. >>>>>> >>>>>> >>>>>> >>>>>> If its required to model these information in metadata, >>>> how do we >>>>>> do them ? >>>>>> >>>>>> >>>>>> >>>>>> I would like to get some thoughts/ inputs from interested >>>> people in >>>>>> the mailing list on whether there is a value add / need >>>> in storing >>>>>> information about streams that are not recorded. >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Ram >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > From john.elwell@siemens-enterprise.com Tue Jan 18 07:34:09 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5A233A7025 for ; Tue, 18 Jan 2011 07:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFWs7zD5HDae for ; Tue, 18 Jan 2011 07:34:09 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id E311E28C0D9 for ; Tue, 18 Jan 2011 07:34:08 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3049733 for siprec@ietf.org; Tue, 18 Jan 2011 16:36:45 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 6D6EF23F0290 for ; Tue, 18 Jan 2011 16:36:45 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 18 Jan 2011 16:36:45 +0100 From: "Elwell, John" To: "siprec@ietf.org" Date: Tue, 18 Jan 2011 16:36:43 +0100 Thread-Topic: Extension to WGLC for siprec-req Thread-Index: Acu3JYIeO0vv8RdvT36l5TlpmKsJ8w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Extension to WGLC for siprec-req X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 15:34:10 -0000 There was a disappointingly poor response to WGLC, which ended yesterday. T= herefore the chairs have decided to extend WGLC until next Monday, 2011-01-= 24 (i.e., to finish the day before the interim virtual meeting). Please sub= mit your comments and/or indicate whether you consider the document ready t= o go by that date. John= From Dave.Smith@genesyslab.com Tue Jan 18 10:33:53 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 287AC3A7055 for ; Tue, 18 Jan 2011 10:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwbjKtat6v5K for ; Tue, 18 Jan 2011 10:33:51 -0800 (PST) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by core3.amsl.com (Postfix) with ESMTP id C797D3A7053 for ; Tue, 18 Jan 2011 10:33:51 -0800 (PST) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id p0IIaTkv027128 for ; Tue, 18 Jan 2011 10:36:29 -0800 (PST) Received: from SARUMAN.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Jan 2011 10:36:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-puzzleid: {E9536BF8-8B2A-4BA5-9DFD-F435C57D5025} MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBB73E.9EB1197E" x-cr-hashedpuzzle: U58= Brkp CA/d DYMr EKOJ ENKo EhWG Eoud FPWk Fp72 GD98 GjnJ Gt1Z Gu7M HK0u IKAi; 1; cwBpAHAAcgBlAGMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {E9536BF8-8B2A-4BA5-9DFD-F435C57D5025}; ZABhAHYAZQAuAHMAbQBpAHQAaABAAGcAZQBuAGUAcwB5AHMAbABhAGIALgBjAG8AbQA=; Tue, 18 Jan 2011 18:36:26 GMT; VABlAHMAdAA= Content-class: urn:content-classes:message Date: Tue, 18 Jan 2011 10:36:26 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Test Thread-Index: Acu3Pp0nYyjJ/uUaTDGm4BfIK+aX6w== From: "Dave Smith" To: X-OriginalArrivalTime: 18 Jan 2011 18:36:28.0939 (UTC) FILETIME=[9EBF65B0:01CBB73E] Subject: [siprec] Test X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 18:33:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBB73E.9EB1197E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just testing if this email is received/sent out by the ietf server. =20 Dave =20 =20 =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 ------_=_NextPart_001_01CBB73E.9EB1197E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jus= t testing if this email is received/sent out by the ietf server.<= /p>

 

Dav= e

 

 

 


CONFIDENTIALITY NOTICE: This e-mai= l and any files attached may contain confidential and proprietary informa= tion of Alcatel-Lucent and/or its affiliated entities. Access by the inte= nded recipient only is authorized. Any liability arising from any party a= cting, or refraining from acting, on any information contained in this e-= mail is hereby excluded. If you are not the intended recipient, please no= tify the sender immediately, destroy the original transmission and its at= tachments and do not disclose the contents to any other person, use it fo= r any purpose, or store or copy the information in any medium. Copyright = in this e-mail and any attachments belongs to Alcatel-Lucent and/or its a= ffiliated entities. ------_=_NextPart_001_01CBB73E.9EB1197E-- From john.elwell@siemens-enterprise.com Wed Jan 19 01:05:07 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6F613A6EB1 for ; Wed, 19 Jan 2011 01:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OepHUibyGVHh for ; Wed, 19 Jan 2011 01:05:07 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id C421A3A6E80 for ; Wed, 19 Jan 2011 01:05:06 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3061960 for siprec@ietf.org; Wed, 19 Jan 2011 10:07:45 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 0A8851EB82AB for ; Wed, 19 Jan 2011 10:07:45 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 19 Jan 2011 10:07:44 +0100 From: "Elwell, John" To: "siprec@ietf.org" Date: Wed, 19 Jan 2011 10:07:43 +0100 Thread-Topic: Question on draft-portman-siprec-protocol-01 Thread-Index: Acu3uFT+nSQilLJDQ2ya7rZQk+il8w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Question on draft-portman-siprec-protocol-01 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 09:05:08 -0000 In the requirements document we have the following requirement: "REQ-005 The mechanism MUST support the ability to record a CS without an intentional loss of media (for example, clipping media at the beginning of the CS) and without impacting the quality or timing of the CS (for example, delaying the start of the CS while preparation for recording takes place). See Use Case 4 in Section 5." Use case 4 is "Persistent Recording". Notwithstanding the current discussion on the wording of REQ-005, I would b= e curious to know how the protocol proposal addresses this "persistent reco= rding" requirement. Cases where there are two or more CSs, in series and/or= in parallel, for a given RS, do not seem to be covered in the protocol dra= ft. The descriptions seem to assume that the initial INVITE request for the= RS occurs at the same time as the initial INVITE request for the CS, and s= imilarly for the BYE request. The only reference I could find was in sectio= n 5, which mentions REQ-004 (presumably a typo - should be REQ-005), but on= ly in the context of having SDP with no m-lines when no CS has been started= . Assuming re-INVITEs would be used to signify the start or end of a CS, how = are metadata and SDP media associated with particular CSs? For example, are new m-lines introduced when a new CS starts? This would me= an the number of m-lines would be constantly increasing until the SDP size = would become unmanageable. This is because the offer-answer model forbids t= he removal of m-lines. Or would existing m-lines be reused for multiple CSs= ? Even then, an SRC that records a large number of CSs in parallel (e.g., a= B2BUA) would generate very large SDPs. Moreover, the SDP will grow as the = number of parallel CSs increases and can never shrink again, so over time t= he RS will be operating with a very large SDP even at times of low traffic. Would the metadata for each CS be carried as a separate body part? This too= would produce extremely large messages. Or is the assumption that a given = SIP request would relate to a change in only a single CS, and therefore wou= ld only need to convey metadata for that one CS? It is important to know what sort of solution we have in mind before we fre= eze the requirements document. If it is not feasible to meet REQ-005 using = the protocol mechanism we have in mind, perhaps we need to reconsider REQ-0= 05. John (as individual) From partr@cisco.com Wed Jan 19 05:40:55 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D97573A712E for ; Wed, 19 Jan 2011 05:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.13 X-Spam-Level: X-Spam-Status: No, score=-10.13 tagged_above=-999 required=5 tests=[AWL=0.469, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iql62J4B8K1 for ; Wed, 19 Jan 2011 05:40:54 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 760123A6F2F for ; Wed, 19 Jan 2011 05:40:54 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUEAKt5Nk2Q/khNgWdsb2JhbACkRBUBARYiJKYLmjCFUASEbYlb Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 19 Jan 2011 13:43:33 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p0JDhXvU024164; Wed, 19 Jan 2011 13:43:33 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 19:13:32 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Jan 2011 19:13:32 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Question on draft-portman-siprec-protocol-01 Thread-Index: Acu3uFT+nSQilLJDQ2ya7rZQk+il8wAIouew References: From: "Parthasarathi R (partr)" To: "Elwell, John" , X-OriginalArrivalTime: 19 Jan 2011 13:43:32.0517 (UTC) FILETIME=[DCCBFD50:01CBB7DE] Subject: Re: [siprec] Question on draft-portman-siprec-protocol-01 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 13:40:55 -0000 John, I completely agree with you in case m-line has to be added with each new CS creation. So, adding m-line for CS is not the solution. For UA, it is possible to create RS in advance and use it whenever CS is created. This solution is sub-optimal but discussed during pre-IETF-78 interim meeting. For B2BUA, the pool of RS shall be created, RS will be allocated to CSG (CS group) whenever CSG is created, RS will be freed to pool whenever CSG is completed. Again it is sub-optimal solution as lot of RS dialog will be idle. In case RS is created after CS establishment, the initial media packets in CS shall be buffered in SRC till RS is established and passed later with the same delay towards SRS till the end of the session. Here, there is a delay in recording and also more memory/CPU required in SRC to queue the packets and dequeue packets. Let us see any other better mechanism exists to solve this issue. Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John Sent: Wednesday, January 19, 2011 2:38 PM To: siprec@ietf.org Subject: [siprec] Question on draft-portman-siprec-protocol-01 In the requirements document we have the following requirement: "REQ-005 The mechanism MUST support the ability to record a CS without an intentional loss of media (for example, clipping media at the beginning of the CS) and without impacting the quality or timing of the CS (for example, delaying the start of the CS while preparation for recording takes place). See Use Case 4 in Section 5." Use case 4 is "Persistent Recording". Notwithstanding the current discussion on the wording of REQ-005, I would be curious to know how the protocol proposal addresses this "persistent recording" requirement. Cases where there are two or more CSs, in series and/or in parallel, for a given RS, do not seem to be covered in the protocol draft. The descriptions seem to assume that the initial INVITE request for the RS occurs at the same time as the initial INVITE request for the CS, and similarly for the BYE request. The only reference I could find was in section 5, which mentions REQ-004 (presumably a typo - should be REQ-005), but only in the context of having SDP with no m-lines when no CS has been started. Assuming re-INVITEs would be used to signify the start or end of a CS, how are metadata and SDP media associated with particular CSs? For example, are new m-lines introduced when a new CS starts? This would mean the number of m-lines would be constantly increasing until the SDP size would become unmanageable. This is because the offer-answer model forbids the removal of m-lines. Or would existing m-lines be reused for multiple CSs? Even then, an SRC that records a large number of CSs in parallel (e.g., a B2BUA) would generate very large SDPs. Moreover, the SDP will grow as the number of parallel CSs increases and can never shrink again, so over time the RS will be operating with a very large SDP even at times of low traffic. Would the metadata for each CS be carried as a separate body part? This too would produce extremely large messages. Or is the assumption that a given SIP request would relate to a change in only a single CS, and therefore would only need to convey metadata for that one CS? It is important to know what sort of solution we have in mind before we freeze the requirements document. If it is not feasible to meet REQ-005 using the protocol mechanism we have in mind, perhaps we need to reconsider REQ-005. John (as individual) _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@cisco.com Wed Jan 19 06:26:18 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D96E73A710C for ; Wed, 19 Jan 2011 06:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.493 X-Spam-Level: X-Spam-Status: No, score=-110.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4HT-FTG5h5h for ; Wed, 19 Jan 2011 06:26:17 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4D86C3A70F5 for ; Wed, 19 Jan 2011 06:26:17 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPuDNk1AZnwM/2dsb2JhbACkR3OmDJouhVAEhG+GL4Mk Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 19 Jan 2011 14:28:57 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0JESv1U024629 for ; Wed, 19 Jan 2011 14:28:57 GMT Message-ID: <4D36F529.2070202@cisco.com> Date: Wed, 19 Jan 2011 09:28:57 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: siprec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Question on draft-portman-siprec-protocol-01 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 14:26:19 -0000 John, While you aren't allowed to *remove* m-lines, they can be recycled. I think there are a couple of different ways that persistent RS sessions can work, depending on the needs and capabilities of the SRC: - The SRC could establish an RS *with* m-line(s) for media it expects will be used in CS sessions when they occur. When a CS does begin it can start sending media from the session on the negotiated ports. It can then also send metadata relating the m-lines to a CS. The metadata might arrive a bit later than the media. Not sure if that is a problem. This of course only accommodates anticipated media. If changes to codecs, etc. are required then it will require an o/a. - The SRC could establish an RS with no m-lines. When the first CS begins, it could reinvite to do o/a with m-lines needed for the CS, and also with the corresponding metadata. (Not clear if this is any faster than establishing a new RS, but maybe.) When the CS ends, another reinvite can reject those m-lines (port zero) and include metadata indicating the end of the CS. When a subsequent CS begins, it can recycle the rejected m-lines, putting on new media types, codecs, labels, etc. and coordinating with new metadata for the new CS. Subsequent and additional CSs can use both strategies, adding new m-lines as needed and recycling old ones when possible. - A combination of the above two approaches is also possible. The SRC could pre-negotiate some m-lines for types of media it anticipates may be needed for subsequent CSs and then assign them to a CS when appropriate, while adding new ones when necessary. Thanks, Paul So, I would expect that in a persistent RS session you would start with no m-lines. Then when the first CS begins you would reinvite On 1/19/2011 4:07 AM, Elwell, John wrote: > In the requirements document we have the following requirement: > "REQ-005 The mechanism MUST support the ability to record a CS > without an intentional loss of media (for example, clipping media at > the beginning of the CS) and without impacting the quality or timing > of the CS (for example, delaying the start of the CS while > preparation for recording takes place). See Use Case 4 in Section 5." > Use case 4 is "Persistent Recording". > > Notwithstanding the current discussion on the wording of REQ-005, I would be curious to know how the protocol proposal addresses this "persistent recording" requirement. Cases where there are two or more CSs, in series and/or in parallel, for a given RS, do not seem to be covered in the protocol draft. The descriptions seem to assume that the initial INVITE request for the RS occurs at the same time as the initial INVITE request for the CS, and similarly for the BYE request. The only reference I could find was in section 5, which mentions REQ-004 (presumably a typo - should be REQ-005), but only in the context of having SDP with no m-lines when no CS has been started. > > Assuming re-INVITEs would be used to signify the start or end of a CS, how are metadata and SDP media associated with particular CSs? > > For example, are new m-lines introduced when a new CS starts? This would mean the number of m-lines would be constantly increasing until the SDP size would become unmanageable. This is because the offer-answer model forbids the removal of m-lines. Or would existing m-lines be reused for multiple CSs? Even then, an SRC that records a large number of CSs in parallel (e.g., a B2BUA) would generate very large SDPs. Moreover, the SDP will grow as the number of parallel CSs increases and can never shrink again, so over time the RS will be operating with a very large SDP even at times of low traffic. > > Would the metadata for each CS be carried as a separate body part? This too would produce extremely large messages. Or is the assumption that a given SIP request would relate to a change in only a single CS, and therefore would only need to convey metadata for that one CS? > > It is important to know what sort of solution we have in mind before we freeze the requirements document. If it is not feasible to meet REQ-005 using the protocol mechanism we have in mind, perhaps we need to reconsider REQ-005. > > John (as individual) > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From Henry.Lum@alcatel-lucent.com Wed Jan 19 07:22:32 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B121E3A716D for ; Wed, 19 Jan 2011 07:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.974 X-Spam-Level: X-Spam-Status: No, score=-5.974 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUkiirCYoDwW for ; Wed, 19 Jan 2011 07:22:31 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id B747D3A716C for ; Wed, 19 Jan 2011 07:22:31 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p0JFPBDk005366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jan 2011 09:25:11 -0600 (CST) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [172.22.68.187]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0JFP95C030162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Jan 2011 09:25:11 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id p0JFP9xs001146; Wed, 19 Jan 2011 07:25:09 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 07:25:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Jan 2011 07:25:08 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF740690499F@NAHALD.us.int.genesyslab.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Extension to WGLC for siprec-req Thread-Index: Acu3JYIeO0vv8RdvT36l5TlpmKsJ8wAub1TA References: From: "Henry Lum" To: "Elwell, John" , X-OriginalArrivalTime: 19 Jan 2011 15:25:08.0978 (UTC) FILETIME=[0E921D20:01CBB7ED] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [siprec] Extension to WGLC for siprec-req X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 15:22:32 -0000 I have no comments and I am okay with the draft. Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Tuesday, January 18, 2011 10:37 AM > To: siprec@ietf.org > Subject: [siprec] Extension to WGLC for siprec-req >=20 > There was a disappointingly poor response to WGLC, which ended > yesterday. Therefore the chairs have decided to extend WGLC until next > Monday, 2011-01-24 (i.e., to finish the day before the interim virtual > meeting). Please submit your comments and/or indicate whether you > consider the document ready to go by that date. >=20 > John > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From john.elwell@siemens-enterprise.com Wed Jan 19 09:46:21 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8722D28C119 for ; Wed, 19 Jan 2011 09:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzYqI5hpCsNf for ; Wed, 19 Jan 2011 09:46:20 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 16DE628C113 for ; Wed, 19 Jan 2011 09:46:19 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3072099; Wed, 19 Jan 2011 18:48:59 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 8044D1EB82AB; Wed, 19 Jan 2011 18:48:59 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 19 Jan 2011 18:48:59 +0100 From: "Elwell, John" To: Paul Kyzivat , "siprec@ietf.org" Date: Wed, 19 Jan 2011 18:48:58 +0100 Thread-Topic: [siprec] Question on draft-portman-siprec-protocol-01 Thread-Index: Acu35Tggr9hFX5qCRk+LW2iCU8ULeQAG9W5A Message-ID: References: <4D36F529.2070202@cisco.com> In-Reply-To: <4D36F529.2070202@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Question on draft-portman-siprec-protocol-01 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 17:46:21 -0000 Yes, those seem to be the choices. I think the draft should cover some of t= his. John =20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 19 January 2011 14:29 > To: siprec@ietf.org > Subject: Re: [siprec] Question on draft-portman-siprec-protocol-01 >=20 > John, >=20 > While you aren't allowed to *remove* m-lines, they can be recycled. > I think there are a couple of different ways that persistent=20 > RS sessions=20 > can work, depending on the needs and capabilities of the SRC: >=20 > - The SRC could establish an RS *with* m-line(s) for media it expects > will be used in CS sessions when they occur. When a CS does begin > it can start sending media from the session on the=20 > negotiated ports. > It can then also send metadata relating the m-lines to a CS. The > metadata might arrive a bit later than the media. Not sure if that > is a problem. This of course only accommodates anticipated media. > If changes to codecs, etc. are required then it will=20 > require an o/a. >=20 > - The SRC could establish an RS with no m-lines. When the first CS > begins, it could reinvite to do o/a with m-lines needed for the CS, > and also with the corresponding metadata. (Not clear if this is any > faster than establishing a new RS, but maybe.) >=20 > When the CS ends, another reinvite can reject those m-lines (port > zero) and include metadata indicating the end of the CS. >=20 > When a subsequent CS begins, it can recycle the rejected m-lines, > putting on new media types, codecs, labels, etc. and coordinating > with new metadata for the new CS. >=20 > Subsequent and additional CSs can use both strategies, adding new > m-lines as needed and recycling old ones when possible. >=20 > - A combination of the above two approaches is also possible. The SRC > could pre-negotiate some m-lines for types of media it anticipates > may be needed for subsequent CSs and then assign them to a CS when > appropriate, while adding new ones when necessary. >=20 > Thanks, > Paul >=20 > So, I would expect that in a persistent RS session you would=20 > start with=20 > no m-lines. Then when the first CS begins you would reinvite >=20 > On 1/19/2011 4:07 AM, Elwell, John wrote: > > In the requirements document we have the following requirement: > > "REQ-005 The mechanism MUST support the ability to record a CS > > without an intentional loss of media (for example,=20 > clipping media at > > the beginning of the CS) and without impacting the=20 > quality or timing > > of the CS (for example, delaying the start of the CS while > > preparation for recording takes place). See Use Case 4=20 > in Section 5." > > Use case 4 is "Persistent Recording". > > > > Notwithstanding the current discussion on the wording of=20 > REQ-005, I would be curious to know how the protocol proposal=20 > addresses this "persistent recording" requirement. Cases=20 > where there are two or more CSs, in series and/or in=20 > parallel, for a given RS, do not seem to be covered in the=20 > protocol draft. The descriptions seem to assume that the=20 > initial INVITE request for the RS occurs at the same time as=20 > the initial INVITE request for the CS, and similarly for the=20 > BYE request. The only reference I could find was in section=20 > 5, which mentions REQ-004 (presumably a typo - should be=20 > REQ-005), but only in the context of having SDP with no=20 > m-lines when no CS has been started. > > > > Assuming re-INVITEs would be used to signify the start or=20 > end of a CS, how are metadata and SDP media associated with=20 > particular CSs? > > > > For example, are new m-lines introduced when a new CS=20 > starts? This would mean the number of m-lines would be=20 > constantly increasing until the SDP size would become=20 > unmanageable. This is because the offer-answer model forbids=20 > the removal of m-lines. Or would existing m-lines be reused=20 > for multiple CSs? Even then, an SRC that records a large=20 > number of CSs in parallel (e.g., a B2BUA) would generate very=20 > large SDPs. Moreover, the SDP will grow as the number of=20 > parallel CSs increases and can never shrink again, so over=20 > time the RS will be operating with a very large SDP even at=20 > times of low traffic. > > > > Would the metadata for each CS be carried as a separate=20 > body part? This too would produce extremely large messages.=20 > Or is the assumption that a given SIP request would relate to=20 > a change in only a single CS, and therefore would only need=20 > to convey metadata for that one CS? > > > > It is important to know what sort of solution we have in=20 > mind before we freeze the requirements document. If it is not=20 > feasible to meet REQ-005 using the protocol mechanism we have=20 > in mind, perhaps we need to reconsider REQ-005. > > > > John (as individual) > > _______________________________________________ > > 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 > = From rmohanr@cisco.com Wed Jan 19 20:17:38 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B01E28C138 for ; Wed, 19 Jan 2011 20:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.475 X-Spam-Level: X-Spam-Status: No, score=-10.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSPbvTNsO2rt for ; Wed, 19 Jan 2011 20:17:37 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 5E6A928C0F6 for ; Wed, 19 Jan 2011 20:17:37 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoGAI5GN01AaMHG/2dsb2JhbACEEpIdjTNoc6JFileQIYEkgzh0BIRtiVs Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-5.cisco.com with ESMTP; 20 Jan 2011 04:20:17 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0K4KFgJ016236 for ; Thu, 20 Jan 2011 04:20:16 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Jan 2011 09:50:15 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 20 Jan 2011 09:50:23 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD05024D77@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ram-siprec-metadata-03 Thread-Index: Acu4WQQUW+MLpKTaTseJmyqbsa8uGAAAA+RQ From: "Ram Mohan R (rmohanr)" To: X-OriginalArrivalTime: 20 Jan 2011 04:20:15.0870 (UTC) FILETIME=[56D6A9E0:01CBB859] Subject: [siprec] FW: New Version Notification for draft-ram-siprec-metadata-03 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 04:17:38 -0000 SGkgQWxsLA0KDQpTdWJtaXR0ZWQgdGhlIG5leHQgdmVyc2lvbiBvZiBtZXRhZGF0YSBtb2RlbCB3 aGljaCBoYXM6DQoNCi0gVXBkYXRlZCBNZXRhZGF0YSBtb2RlbCBpbiBTZWN0aW9uIDMuIE5vdyBN ZWRpYSBTdHJlYW0gYmxvY2sgaXMgZGlyZWN0bHkgY29ubmVjdGVkIHRvIENTIGFsb25nIHdpdGgg cGFydGljaXBhbnRzLiBUaGlzIGlzIG5lZWRlZCBiZWNhdXNlIGEgc3RyZWFtIHdpdGggWmVybyBw YXJ0aWNpcGFudCB3aWxsIGJlIGhhbmdpbmcgc3RyZWFtIHdoaWNoIHdpbGwgbm90IGJlIGFzc29j aWF0ZWQgZGlyZWN0bHkgd2l0aCBDUy4gU28gd2UgbmVlZCBleHBsaWNpdCByZWZlcmVuY2VzIGJl dHdlZW4gc3RyZWFtcyBhbmQgQ1NzLiAoTGlua2luZyB0aGVtIGJ5IHBhcnRpY2lwYW50IGlzbid0 IHN1ZmZpY2llbnQuKSANCi0gTW9kaWZpZWQgdGhlIGRyYWZ0IHdpdGggdGhlIGNvbW1lbnRzIGNs b3NlZCAoIG9uIGRpZmZlcmVudCBhdHRyaWJ1dGVzIG9mIG1ldGFtb2RlbCBhbmQgdGhlIGFzc29j aWF0aW9ucykgZHVyaW5nIERlYyAxNnRoIDIwMTAgSW50ZXJpbSBtZWV0aW5nLg0KLSBVcGRhdGVk IHRoZSBvYmplY3QgaW5zdGFuY2VzIHRvIHNob3cgdGhlIENTIHRvIE1lZGlhIFN0cmVhbSBhc3Nv Y2lhdGlvbnMNCg0KVGhlIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBpcyBhdmFpbGFibGUgYXQN Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJhbS1zaXByZWMtbWV0YWRh dGEvDQoNClBsZWFzZSByZXZpZXcgYW5kIHByb3ZpZGUgeW91ciBjb21tZW50cy9pbnB1dHMNCg0K V2Ugd2lsbCBkaXNjdXNzIG1vcmUgYWJvdXQgdGhlIHVwZGF0ZXMgZG9uZSB0byB2ZXItMDMgZHVy aW5nIHRoZSBpbnRlcmltIG1lZXRpbmcgbmV4dCB3ZWVrLg0KDQpSZWdhcmRzLA0KUmFtDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJRVRGIEktRCBTdWJtaXNzaW9uIFRvb2wg W21haWx0bzppZHN1Ym1pc3Npb25AaWV0Zi5vcmddIA0KU2VudDogVGh1cnNkYXksIEphbnVhcnkg MjAsIDIwMTEgOTo0NSBBTQ0KVG86IFJhbSBNb2hhbiBSIChybW9oYW5yKQ0KQ2M6IFBhcnRoYXNh cmF0aGkgUiAocGFydHIpOyBQYXVsIEt5eml2YXQgKHBreXppdmF0KQ0KU3ViamVjdDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1yYW0tc2lwcmVjLW1ldGFkYXRhLTAzIA0KDQoN CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1yYW0tc2lwcmVjLW1ldGFkYXRhLTAzLnR4dCBo YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFJhbSBSIGFuZCBwb3N0ZWQgdG8gdGhl IElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1yYW0tc2lwcmVjLW1ldGFkYXRh DQpSZXZpc2lvbjoJIDAzDQpUaXRsZToJCSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJ UCkgUmVjb3JkaW5nIE1ldGFkYXRhDQpDcmVhdGlvbl9kYXRlOgkgMjAxMS0wMS0yMA0KV0cgSUQ6 CQkgSW5kZXBlbmRlbnQgU3VibWlzc2lvbg0KTnVtYmVyX29mX3BhZ2VzOiAxNw0KDQpBYnN0cmFj dDoNClNlc3Npb24gcmVjb3JkaW5nIGlzIGEgY3JpdGljYWwgcmVxdWlyZW1lbnQgaW4gbWFueSBj b21tdW5pY2F0aW9ucw0KZW52aXJvbm1lbnRzIHN1Y2ggYXMgY2FsbCBjZW50ZXJzIGFuZCBmaW5h bmNpYWwgdHJhZGluZy4gIEluIHNvbWUgb2YNCnRoZXNlIGVudmlyb25tZW50cywgYWxsIGNhbGxz IG11c3QgYmUgcmVjb3JkZWQgZm9yIHJlZ3VsYXRvcnksDQpjb21wbGlhbmNlLCBhbmQgY29uc3Vt ZXIgcHJvdGVjdGlvbiByZWFzb25zLiAgUmVjb3JkaW5nIG9mIGEgc2Vzc2lvbg0KaXMgdHlwaWNh bGx5IHBlcmZvcm1lZCBieSBzZW5kaW5nIGEgY29weSBvZiBhIG1lZGlhIHN0cmVhbSB0byBhDQpy ZWNvcmRpbmcgZGV2aWNlLiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIG1ldGFkYXRhIG1v ZGVsIGFzDQp2aWV3ZWQgYnkgU2Vzc2lvbiBSZWNvcmRpbmcgU2VydmVyKFNSUykuDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQuDQoNCg0K From john.elwell@siemens-enterprise.com Thu Jan 20 00:14:57 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F9D03A70EE for ; Thu, 20 Jan 2011 00:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zS6nHouSLAgn for ; Thu, 20 Jan 2011 00:14:56 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 610393A70F3 for ; Thu, 20 Jan 2011 00:14:56 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3074968 for siprec@ietf.org; Thu, 20 Jan 2011 09:17:37 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 81C4523F0278 for ; Thu, 20 Jan 2011 09:17:37 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 20 Jan 2011 09:17:37 +0100 From: "Elwell, John" To: "siprec@ietf.org" Date: Thu, 20 Jan 2011 09:17:35 +0100 Thread-Topic: Scope of metadata model draft and its relationship to protocol draft Thread-Index: Acu4en58farWU7zSS561t4KfBOYbNg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Scope of metadata model draft and its relationship to protocol draft X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 08:14:57 -0000 Ram, The title and introduction of the metadata model draft suggest it is limite= d to specification of the model. In addition to that, we will need to speci= fy how the model is encoded for transport, and how it is transported. It lo= oks like transport will be covered by the protocol draft, but this still le= aves encoding. I would imagine we might want an XML schema, for example. Wo= uld this eventually be part of the metadata model draft? I understand there= are still issues as to which metadata is already covered by existing SIP/S= DP elements and which needs to be conveyed explicitly as metadata, so it mi= ght be too early to develop the schema yet, but it would be good to have a = plan on how the documentation will link together. On the assumption that transport is to be covered in the protocol draft, th= ere are a few normative statements in the metadata model draft that might b= e out of place. For example: - "The Session Recording Client (SRC) MAY initiate the Recording Session." - "The metadata MUST be conveyed from SRC to SRS." - "The metadata MAY be conveyed in Recording Session Dialog." - "It is RECOMMENDED that a SRC authenticate SRS using the normal SIP authentication mechanisms" - and in fact the whole of 6.1 possibly doesn't belong in this document. John (as individual)= From john.elwell@siemens-enterprise.com Thu Jan 20 00:15:03 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED2003A71B3 for ; Thu, 20 Jan 2011 00:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjM891i+IH5F for ; Thu, 20 Jan 2011 00:15:03 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id CF8D23A71B1 for ; Thu, 20 Jan 2011 00:15:02 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3068644 for siprec@ietf.org; Thu, 20 Jan 2011 09:17:44 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 821A423F0290 for ; Thu, 20 Jan 2011 09:17:44 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 20 Jan 2011 09:17:45 +0100 From: "Elwell, John" To: "siprec@ietf.org" Date: Thu, 20 Jan 2011 09:17:43 +0100 Thread-Topic: Application Data in the metadata model Thread-Index: Acu4eoL7mYwoCikvQpaPyiY2ncCoQg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Application Data in the metadata model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 08:15:04 -0000 Ram, This has probably been discussed before, but why is Application Data a sepa= rate object class, as opposed to being attributes of the various other obje= ct classes. In particular, I find the cardinalities of Application Data's a= ssociations with other classes hard to understand. Why would an Application= Data object be associated with a single RS, a single CSG, a single CS, a s= ingle Participant, and a single Media Stream all at the same time? Or I am = interpreting the figure wrong? John (as individual)= From john.elwell@siemens-enterprise.com Thu Jan 20 00:23:40 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DEA43A6F95 for ; Thu, 20 Jan 2011 00:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REX8UVbrRQ6i for ; Thu, 20 Jan 2011 00:23:39 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 0B2D73A70EE for ; Thu, 20 Jan 2011 00:23:38 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3077650 for siprec@ietf.org; Thu, 20 Jan 2011 09:26:20 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 80FFF1EB82AB for ; Thu, 20 Jan 2011 09:26:20 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 20 Jan 2011 09:26:21 +0100 From: "Elwell, John" To: "siprec@ietf.org" Date: Thu, 20 Jan 2011 09:26:18 +0100 Thread-Topic: What happened to the 'recorded' feature tag? Thread-Index: Acu4e7ZHuMXzeIv2QAiy+CmZO3LH4g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] What happened to the 'recorded' feature tag? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 08:23:40 -0000 Draft-johnston-siprec-cc-rec specified 3 media feature tags. Two of them, '= src' and 'srs', have been moved to draft-portman-siprec-protocol, as part o= f the merger of the two drafts. The third one, 'recorded', for use on the C= S, has been dropped. I recognise this is not part of the "SIPREC protocol" = between SRC and SRS, but nevertheless it seems to be a solution to one of t= he SIPREC requirements. What are the intentions of the draft authors? John= From Henry.Lum@alcatel-lucent.com Thu Jan 20 01:08:04 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D47528C0FB for ; Thu, 20 Jan 2011 01:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.016 X-Spam-Level: X-Spam-Status: No, score=-6.016 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQ4E5Xbr1d7m for ; Thu, 20 Jan 2011 01:08:03 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 9E92328C0E6 for ; Thu, 20 Jan 2011 01:08:03 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p0K9AiZ4000629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jan 2011 03:10:45 -0600 (CST) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [172.22.68.187]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0K9Ah01023983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Jan 2011 03:10:44 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id p0K9AgiB017188; Thu, 20 Jan 2011 01:10:42 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Jan 2011 01:10:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Jan 2011 01:07:46 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF7406904BD3@NAHALD.us.int.genesyslab.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] What happened to the 'recorded' feature tag? Thread-Index: Acu4e7ZHuMXzeIv2QAiy+CmZO3LH4gABT9nw References: From: "Henry Lum" To: "Elwell, John" , X-OriginalArrivalTime: 20 Jan 2011 09:10:42.0385 (UTC) FILETIME=[E9D9D410:01CBB881] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [siprec] What happened to the 'recorded' feature tag? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 09:08:04 -0000 The intention for this draft is to include any extensions to address recording-aware endpoints for the following requirements: REQ-15, 016, 017, 018 These requirements are currently not addressed in the protocol draft. Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Thursday, January 20, 2011 3:26 AM > To: siprec@ietf.org > Subject: [siprec] What happened to the 'recorded' feature tag? >=20 > Draft-johnston-siprec-cc-rec specified 3 media feature tags. Two of > them, 'src' and 'srs', have been moved to draft-portman-siprec- > protocol, as part of the merger of the two drafts. The third one, > 'recorded', for use on the CS, has been dropped. I recognise this is > not part of the "SIPREC protocol" between SRC and SRS, but nevertheless > it seems to be a solution to one of the SIPREC requirements. What are > the intentions of the draft authors? >=20 > John > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From john.elwell@siemens-enterprise.com Thu Jan 20 01:30:15 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7084E3A7218 for ; Thu, 20 Jan 2011 01:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFQUOATv9Zyv for ; Thu, 20 Jan 2011 01:30:14 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 4282A28C0EC for ; Thu, 20 Jan 2011 01:30:13 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3076106; Thu, 20 Jan 2011 10:32:55 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 6043F1EB82AB; Thu, 20 Jan 2011 10:32:55 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 20 Jan 2011 10:32:55 +0100 From: "Elwell, John" To: Henry Lum , "siprec@ietf.org" Date: Thu, 20 Jan 2011 10:32:53 +0100 Thread-Topic: [siprec] What happened to the 'recorded' feature tag? Thread-Index: Acu4e7ZHuMXzeIv2QAiy+CmZO3LH4gABT9nwAADriZA= Message-ID: References: <059AF07365DC474393A19A3AF187DF7406904BD3@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF7406904BD3@NAHALD.us.int.genesyslab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] What happened to the 'recorded' feature tag? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 09:30:15 -0000 Henry, Thanks for the clarification. The particular requirement I picked on (REQ-0= 18) is indeed not the only requirement still to be addressed. If the intent= ion is to cover these remaining requirements in the protocol draft, we shou= ld perhaps get these in before considering adoption as a WG draft. John=20 > -----Original Message----- > From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com]=20 > Sent: 20 January 2011 09:08 > To: Elwell, John; siprec@ietf.org > Subject: RE: [siprec] What happened to the 'recorded' feature tag? >=20 > The intention for this draft is to include any extensions to address > recording-aware endpoints for the following requirements: >=20 > REQ-15, 016, 017, 018 >=20 > These requirements are currently not addressed in the protocol draft. >=20 > Henry >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > > Sent: Thursday, January 20, 2011 3:26 AM > > To: siprec@ietf.org > > Subject: [siprec] What happened to the 'recorded' feature tag? > >=20 > > Draft-johnston-siprec-cc-rec specified 3 media feature tags. Two of > > them, 'src' and 'srs', have been moved to draft-portman-siprec- > > protocol, as part of the merger of the two drafts. The third one, > > 'recorded', for use on the CS, has been dropped. I recognise this is > > not part of the "SIPREC protocol" between SRC and SRS, but > nevertheless > > it seems to be a solution to one of the SIPREC=20 > requirements. What are > > the intentions of the draft authors? > >=20 > > John > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec >=20 > =09 > -------------------------------------------------------------- > ----------------------------------------------------- > CONFIDENTIALITY NOTICE: This e-mail and any files attached=20 > may contain confidential and proprietary information of=20 > Alcatel-Lucent and/or its affiliated entities. Access by the=20 > intended recipient only is authorized. Any liability arising=20 > from any party acting, or refraining from acting, on any=20 > information contained in this e-mail is hereby excluded. If=20 > you are not the intended recipient, please notify the sender=20 > immediately, destroy the original transmission and its=20 > attachments and do not disclose the contents to any other=20 > person, use it for any purpose, or store or copy the=20 > information in any medium. Copyright in this e-mail and any=20 > attachments belongs to Alcatel-Lucent and/or its affiliated entities. > =09 > = From john.elwell@siemens-enterprise.com Thu Jan 20 02:37:41 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 051B03A6F75 for ; Thu, 20 Jan 2011 02:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCuaWCg9XDMW for ; Thu, 20 Jan 2011 02:37:40 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id DD5303A70D8 for ; Thu, 20 Jan 2011 02:37:39 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3070921 for siprec@ietf.org; Thu, 20 Jan 2011 11:40:21 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id B6B5C1EB82AB for ; Thu, 20 Jan 2011 11:40:21 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 20 Jan 2011 11:40:21 +0100 From: "Elwell, John" To: "siprec@ietf.org" Date: Thu, 20 Jan 2011 11:39:53 +0100 Thread-Topic: Agenda for interim virtual meetings on 25th and 26th Thread-Index: Acu4jl838/aUFGGmQruL0hQAehHbLA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Agenda for interim virtual meetings on 25th and 26th X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 10:37:41 -0000 Below is the proposed agenda: Session 1 - Tuesday, 15.00-17.00 GMT =20 Administrivia =20 Requirements (issues from WGLC) https://datatracker.ietf.org/doc/draft-ietf-siprec-req/=20 30 min Leon, Ken =20 Metadata model https://datatracker.ietf.org/doc/draft-ram-siprec-metadata/=20 45 min Ram =20 Protocol https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/=20 30 min Leon, Henry =20 Wrap-up - Plans for Wednesday session 5 min=20 chairs =20 =20 Session 2 - Wednesday, 14.00-16.00 GMT =20 Metadata format 45 min (to be posted) Ram =20 Protocol (continued) https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/=20 30 min Leon, Henry =20 Wrap-up - Hums and Next Steps 15 min chairs = From rmohanr@cisco.com Thu Jan 20 03:20:48 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E4813A7031 for ; Thu, 20 Jan 2011 03:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.182 X-Spam-Level: X-Spam-Status: No, score=-10.182 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyIi2aZ+M+iu for ; Thu, 20 Jan 2011 03:20:47 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 1D2EA28C0E3 for ; Thu, 20 Jan 2011 03:20:47 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGaqN01AaMHG/2dsb2JhbACkUXOjB5p7hVAEhG2JWw Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-1.cisco.com with ESMTP; 20 Jan 2011 11:23:29 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0KBNOtd002700; Thu, 20 Jan 2011 11:23:26 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Jan 2011 16:53:24 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Jan 2011 16:51:05 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD05024F5B@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Application Data in the metadata model Thread-Index: Acu4eoL7mYwoCikvQpaPyiY2ncCoQgAFIytQ References: From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , X-OriginalArrivalTime: 20 Jan 2011 11:23:24.0446 (UTC) FILETIME=[739BEBE0:01CBB894] Subject: Re: [siprec] Application Data in the metadata model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 11:20:48 -0000 Hi John, Thanks for the review Please see inline > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Thursday, January 20, 2011 1:48 PM > To: siprec@ietf.org > Subject: [siprec] Application Data in the metadata model >=20 > Ram, >=20 > This has probably been discussed before, but why is Application Data a > separate object class, as opposed to being attributes of the various > other object classes. App Data is for vendor specific data that may be sent for session. So I doubt if that can be as attributes inside a block. In particular, I find the cardinalities of > Application Data's associations with other classes hard to understand. > Why would an Application Data object be associated with a single RS, a > single CSG, a single CS, a single Participant, and a single Media > Stream all at the same time? Or I am interpreting the figure wrong? I intend to say that there are different instances of App Data, and a given instance of App Data has be associated to only one block. I will add some text in the draft to reflect the same. As of now, there can be Zero (there may be elements for which we don't need App Data at all) or more instances of App Data for each of the metadata element blocks(in most cases one should be enough) and a given instance of App Data MUST be associated with only one block.=20 Thanks, Ram >=20 > John (as individual) > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Thu Jan 20 05:32:27 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 139283A7113 for ; Thu, 20 Jan 2011 05:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.573 X-Spam-Level: X-Spam-Status: No, score=-0.573 tagged_above=-999 required=5 tests=[AWL=-1.873, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIZig+e54OxF for ; Thu, 20 Jan 2011 05:32:26 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id E65153A6DAA for ; Thu, 20 Jan 2011 05:32:25 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3074352; Thu, 20 Jan 2011 14:35:08 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 3063B23F0290; Thu, 20 Jan 2011 14:35:08 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 20 Jan 2011 14:35:08 +0100 From: "Hutton, Andrew" To: Leon Portman , "siprec@ietf.org" Date: Thu, 20 Jan 2011 14:35:07 +0100 Thread-Topic: WGLC comments on siprec-req-06 - AndyH Thread-Index: Acu2a/zhy6Eu2cCcTnKTjGmC9q4ZGwAb5lQgAHJVrpA= Message-ID: <101C6067BEC68246B0C3F6843BCCC1E30ABAA9C16B@MCHP058A.global-ad.net> References: <101C6067BEC68246B0C3F6843BCCC1E30ABA829449@MCHP058A.global-ad.net> <07465C1D981ABC41A344374066AE1A2C389F44871A@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C389F44871A@TLVMBX01.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] WGLC comments on siprec-req-06 - AndyH X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 13:32:27 -0000 See my responses to Leon's comments below included suggested text for an ne= w multiple media stream requirement. Regards Andy > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com]=20 > Sent: 18 January 2011 06:53 > To: Hutton, Andrew; siprec@ietf.org > Subject: RE: WGLC comments on siprec-req-06 - AndyH >=20 > Andy, Hi >=20 > Thank you for the comments > Please see below >=20 > Leob >=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Hutton, Andrew > Sent: Monday, January 17, 2011 7:29 PM > To: siprec@ietf.org > Subject: [siprec] WGLC comments on siprec-req-06 - AndyH >=20 > A few WGLC comments on the draft. >=20 > 1. Abstract: "Recording is typically done by". Maybe could=20 > replace "done" with "achieved" or "perfomed". >=20 > [leon] don't have any strong opinion about it >=20 > 2. Definitions, 2nd Para":=20 > "The SRC itself or another entity working on its behalf (such=20 > as a SIP Application Server) may act as the source of the=20 > recording metadata." > I believe it is the SRC which is always the source of the=20 > metadata. However of course the SRC could be decomposed in=20 > various ways but it is still a component of the SRC which is=20 > the source of metadata. If an SRC receives information from=20 > somewhere else which it uses as metadata then that is also=20 > out of scope. >=20 > [leon] I don't think that we should limit scope in such way.=20 > Why do we care if SRC received metadata from some other=20 > entity, like CTI server for backward compatibility case? [Andy H] - We don't care how the SRC receives the metadata however for the= purposes of SIPREC we assume that the SRC is the only entity that sends me= tadata to the SRS. The current text could be interpreted as indicating that= something other than the SRC is able to send metadata to the SRS which is = I believe incorrect. > =20 > 3. Section 4, Use Case 1:=20 > "Use Case 1: Full-time Recording: One (or more, in the case of > redundant recording) Recording Session for each Communication > Session." > There is no other reference to "redundant recording" in the=20 > document I think we should therefore remove this statement. I=20 > think we agreed that this was just an implementation option=20 > and did not need to be a requirement > [leon] May be "duplicate" will be a better term? It is just=20 > an example, and not actual requirement >=20 [Andy H] My preference would be to remove statements all statements on "Red= undant" or "Duplicate" recording. > 4. Section 5, Req 10. > "REQ-010 The mechanism MUST support the ability to deliver to the > SRS multiple media streams for a given CS." > Does this refer to the case of multiple media types (E.g.=20 > Voice, Video etc.) or does it mean multiple media streams of=20 > the same type (i.e. one per participant)? I think we might=20 > need to explicitly state a requirement for unmixed audio=20 > streams from different parties. > [leon] Yes, it means actually both. It is obvious for=20 > different types and not so obvious for unmixed streams >=20 [Andy H] - Agreed so we need a REQ-XX which might state "The mechanism MUST= support the ability to deliver to the SRS multiple media streams of the sa= me media type (e.g. audio, video). For example in the case of delivering un= mixed audio for each participant in the CS".=20 > Regards > Andy >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From john.elwell@siemens-enterprise.com Thu Jan 20 05:56:33 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EC9B3A711A for ; Thu, 20 Jan 2011 05:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.222 X-Spam-Level: X-Spam-Status: No, score=-102.222 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zH7U5T8WelAj for ; Thu, 20 Jan 2011 05:56:32 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 4863B3A7117 for ; Thu, 20 Jan 2011 05:56:31 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3074840; Thu, 20 Jan 2011 14:58:14 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id CAB7923F0278; Thu, 20 Jan 2011 14:58:14 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 20 Jan 2011 14:58:15 +0100 From: "Elwell, John" To: "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Date: Thu, 20 Jan 2011 14:58:14 +0100 Thread-Topic: [siprec] Application Data in the metadata model Thread-Index: Acu4eoL7mYwoCikvQpaPyiY2ncCoQgAFIytQAAYqshA= Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD05024F5B@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD05024F5B@XMB-BGL-417.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Application Data in the metadata model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 13:56:33 -0000 =20 > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 > Sent: 20 January 2011 11:21 > To: Elwell, John; siprec@ietf.org > Subject: RE: [siprec] Application Data in the metadata model >=20 > Hi John, > Thanks for the review > Please see inline >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > > Sent: Thursday, January 20, 2011 1:48 PM > > To: siprec@ietf.org > > Subject: [siprec] Application Data in the metadata model > >=20 > > Ram, > >=20 > > This has probably been discussed before, but why is=20 > Application Data a > > separate object class, as opposed to being attributes of the various > > other object classes. >=20 > App Data is for vendor specific data that may be sent for=20 > session. So I > doubt if that can be as attributes inside a block. [JRE] It still strikes me as a property of other objects. For example, a pa= rticipant can have application data that says something about the participa= nt, e.g., adds to the description of the participant. But that application = data doesn't have associations with any other objects. So I am not convince= d, but I can accept whatever consensus others may reach. >=20 > In particular, I find the cardinalities of > > Application Data's associations with other classes hard to=20 > understand. > > Why would an Application Data object be associated with a=20 > single RS, a > > single CSG, a single CS, a single Participant, and a single Media > > Stream all at the same time? Or I am interpreting the figure wrong? >=20 > I intend to say that there are different instances of App Data, and a > given instance of App Data has be associated to only one block. > I will add some text in the draft to reflect the same. > As of now, there can be Zero (there may be elements for which we don't > need App Data at all) or more instances of App Data for each of the > metadata element blocks(in most cases one should be enough)=20 > and a given > instance of App Data MUST be associated with only one block.=20 [JRE] Yes, I understand this, but I don't know how to model it. I am sure t= here must be a formal way. John >=20 > Thanks, > Ram >=20 > >=20 > > John (as individual) > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > = From pkyzivat@cisco.com Thu Jan 20 06:18:49 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97EEE3A710E for ; Thu, 20 Jan 2011 06:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.197 X-Spam-Level: X-Spam-Status: No, score=-110.197 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9D+UZ4u+A2ua for ; Thu, 20 Jan 2011 06:18:48 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 884663A6FB0 for ; Thu, 20 Jan 2011 06:18:48 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACLTN01AZnwM/2dsb2JhbACkUXOjM5sDhVAEhG+GL4Mk Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 20 Jan 2011 14:21:31 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0KELVb6025209 for ; Thu, 20 Jan 2011 14:21:31 GMT Message-ID: <4D3844EA.6060402@cisco.com> Date: Thu, 20 Jan 2011 09:21:30 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: siprec@ietf.org References: <35BCE99A477D6A4986FB2216D8CF2CFD05024F5B@XMB-BGL-417.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Application Data in the metadata model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 14:18:49 -0000 IMO appdata is just a way to talk about an extensibility hook for each defined object. We have been having a private conversation about how to encode this in xml. I'm no xml expert, but I was thinking that each object simply end up with a sequence of ANY to cover the appdata. An alternative view is that we define an appdata xml entity that contains a sequence of ANY. I'm going to defer to an xml expert for the best way to encode such stuff. Thanks, Paul On 1/20/2011 8:58 AM, Elwell, John wrote: > > > >> -----Original Message----- >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >> Sent: 20 January 2011 11:21 >> To: Elwell, John; siprec@ietf.org >> Subject: RE: [siprec] Application Data in the metadata model >> >> Hi John, >> Thanks for the review >> Please see inline >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Elwell, John >>> Sent: Thursday, January 20, 2011 1:48 PM >>> To: siprec@ietf.org >>> Subject: [siprec] Application Data in the metadata model >>> >>> Ram, >>> >>> This has probably been discussed before, but why is >> Application Data a >>> separate object class, as opposed to being attributes of the various >>> other object classes. >> >> App Data is for vendor specific data that may be sent for >> session. So I >> doubt if that can be as attributes inside a block. > [JRE] It still strikes me as a property of other objects. For example, a participant can have application data that says something about the participant, e.g., adds to the description of the participant. But that application data doesn't have associations with any other objects. So I am not convinced, but I can accept whatever consensus others may reach. > >> >> In particular, I find the cardinalities of >>> Application Data's associations with other classes hard to >> understand. >>> Why would an Application Data object be associated with a >> single RS, a >>> single CSG, a single CS, a single Participant, and a single Media >>> Stream all at the same time? Or I am interpreting the figure wrong? >> >> I intend to say that there are different instances of App Data, and a >> given instance of App Data has be associated to only one block. >> I will add some text in the draft to reflect the same. >> As of now, there can be Zero (there may be elements for which we don't >> need App Data at all) or more instances of App Data for each of the >> metadata element blocks(in most cases one should be enough) >> and a given >> instance of App Data MUST be associated with only one block. > [JRE] Yes, I understand this, but I don't know how to model it. I am sure there must be a formal way. > > John > >> >> Thanks, >> Ram >> >>> >>> John (as individual) >>> _______________________________________________ >>> 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 > From andrew.hutton@siemens-enterprise.com Thu Jan 20 06:19:47 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBAF33A710E for ; Thu, 20 Jan 2011 06:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vx0HjWSEbq3d for ; Thu, 20 Jan 2011 06:19:46 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 8DACF3A6FB0 for ; Thu, 20 Jan 2011 06:19:46 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3081958; Thu, 20 Jan 2011 15:22:28 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id CA3991EB82B0; Thu, 20 Jan 2011 15:22:28 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 20 Jan 2011 15:22:28 +0100 From: "Hutton, Andrew" To: "Elwell, John" , Henry Lum , "siprec@ietf.org" , "alan.b.johnston@gmail.com" Date: Thu, 20 Jan 2011 15:22:35 +0100 Thread-Topic: [siprec] What happened to the 'recorded' feature tag? Thread-Index: Acu4e7ZHuMXzeIv2QAiy+CmZO3LH4gABT9nwAADriZAACg+NUA== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E30ABAA9C1E0@MCHP058A.global-ad.net> References: <059AF07365DC474393A19A3AF187DF7406904BD3@NAHALD.us.int.genesyslab.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] What happened to the 'recorded' feature tag? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 14:19:47 -0000 Hi All, Hi all with regard to the 'recorded' feature tag them I don't know why this= was not copied to the new draft I think it should have been. Alan can you = please comment on that. We did update the scope in the 02 draft to make it clear that the protocol = specified also impacted the CS and this was I think because of the 'recorde= d' feature tag. I suggest we put it back in at the next update. Regards Andy =20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: 20 January 2011 09:33 > To: Henry Lum; siprec@ietf.org > Subject: Re: [siprec] What happened to the 'recorded' feature tag? >=20 > Henry, >=20 > Thanks for the clarification. The particular requirement I=20 > picked on (REQ-018) is indeed not the only requirement still=20 > to be addressed. If the intention is to cover these remaining=20 > requirements in the protocol draft, we should perhaps get=20 > these in before considering adoption as a WG draft. >=20 > John=20 >=20 > > -----Original Message----- > > From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com]=20 > > Sent: 20 January 2011 09:08 > > To: Elwell, John; siprec@ietf.org > > Subject: RE: [siprec] What happened to the 'recorded' feature tag? > >=20 > > The intention for this draft is to include any extensions to address > > recording-aware endpoints for the following requirements: > >=20 > > REQ-15, 016, 017, 018 > >=20 > > These requirements are currently not addressed in the=20 > protocol draft. > >=20 > > Henry > >=20 > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Elwell, John > > > Sent: Thursday, January 20, 2011 3:26 AM > > > To: siprec@ietf.org > > > Subject: [siprec] What happened to the 'recorded' feature tag? > > >=20 > > > Draft-johnston-siprec-cc-rec specified 3 media feature=20 > tags. Two of > > > them, 'src' and 'srs', have been moved to draft-portman-siprec- > > > protocol, as part of the merger of the two drafts. The third one, > > > 'recorded', for use on the CS, has been dropped. I=20 > recognise this is > > > not part of the "SIPREC protocol" between SRC and SRS, but > > nevertheless > > > it seems to be a solution to one of the SIPREC=20 > > requirements. What are > > > the intentions of the draft authors? > > >=20 > > > John > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > >=20 > > =09 > > -------------------------------------------------------------- > > ----------------------------------------------------- > > CONFIDENTIALITY NOTICE: This e-mail and any files attached=20 > > may contain confidential and proprietary information of=20 > > Alcatel-Lucent and/or its affiliated entities. Access by the=20 > > intended recipient only is authorized. Any liability arising=20 > > from any party acting, or refraining from acting, on any=20 > > information contained in this e-mail is hereby excluded. If=20 > > you are not the intended recipient, please notify the sender=20 > > immediately, destroy the original transmission and its=20 > > attachments and do not disclose the contents to any other=20 > > person, use it for any purpose, or store or copy the=20 > > information in any medium. Copyright in this e-mail and any=20 > > attachments belongs to Alcatel-Lucent and/or its affiliated=20 > entities. > > =09 > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From alan.b.johnston@gmail.com Thu Jan 20 07:06:51 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 006D63A7124 for ; Thu, 20 Jan 2011 07:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.437 X-Spam-Level: X-Spam-Status: No, score=-103.437 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9GKlwEDWgh8 for ; Thu, 20 Jan 2011 07:06:49 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 3C8203A7006 for ; Thu, 20 Jan 2011 07:06:49 -0800 (PST) Received: by bwz12 with SMTP id 12so700113bwz.31 for ; Thu, 20 Jan 2011 07:09:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=P1UMAkyseoXVMacrUBFYqU7pg1EAExVE/laqf50w/hM=; b=ljYI5Qcmh1mv0+U8E41SjuYf5mOwSuc9kCiXrrU4Crhiu0FLjHOVMH5kKRww4fDbHd qtKVQmaqtXMzRyRXogbeHEBsIIQqaAhhhEOUjRRvyJ94NkIcaO4QEsxmtPP1YWPSlfNx VmL+/oOXJhJqz3mllvQ7JBHM6GRR0NB+8IyZg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Hk0cb5lMNrmJS3JBAZgqC2X41VOIgDvSgxGNDNnj+qAf8Wb3yuvLUBG0L3TzIwQYEa FIPgVrAc5rwa+O34wVXb0lHNQT60vRtE+8R7z3Pal6iScVTBQApNt/j985mSnZOUSsVW i8CkBg2YFyfiTWT5k2pWWa6CZMrmjqj70FWx8= MIME-Version: 1.0 Received: by 10.204.57.13 with SMTP id a13mr2032250bkh.75.1295536170863; Thu, 20 Jan 2011 07:09:30 -0800 (PST) Received: by 10.204.232.15 with HTTP; Thu, 20 Jan 2011 07:09:30 -0800 (PST) In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E30ABAA9C1E0@MCHP058A.global-ad.net> References: <059AF07365DC474393A19A3AF187DF7406904BD3@NAHALD.us.int.genesyslab.com> <101C6067BEC68246B0C3F6843BCCC1E30ABAA9C1E0@MCHP058A.global-ad.net> Date: Thu, 20 Jan 2011 09:09:30 -0600 Message-ID: From: Alan Johnston To: "Hutton, Andrew" Content-Type: multipart/alternative; boundary=001636c5b447420b34049a4885fe Cc: Henry Lum , "siprec@ietf.org" Subject: Re: [siprec] What happened to the 'recorded' feature tag? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 15:06:51 -0000 --001636c5b447420b34049a4885fe Content-Type: text/plain; charset=ISO-8859-1 I thought the consensus of the group was that the notification requirements were to be met by notifications in the media path. The fatal flaw with the feature tag approach was that it was not backwards compatible - an RFC 3261 UA would not render or display this information to the user, and hence some other notification would be needed. We can certainly add it back in if the working group thinks it is useful. - Alan - On Thu, Jan 20, 2011 at 8:22 AM, Hutton, Andrew < andrew.hutton@siemens-enterprise.com> wrote: > Hi All, > > Hi all with regard to the 'recorded' feature tag them I don't know why this > was not copied to the new draft I think it should have been. Alan can you > please comment on that. > > We did update the scope in the 02 draft to make it clear that the protocol > specified also impacted the CS and this was I think because of the > 'recorded' feature tag. > > I suggest we put it back in at the next update. > > Regards > Andy > > > > > > > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: 20 January 2011 09:33 > > To: Henry Lum; siprec@ietf.org > > Subject: Re: [siprec] What happened to the 'recorded' feature tag? > > > > Henry, > > > > Thanks for the clarification. The particular requirement I > > picked on (REQ-018) is indeed not the only requirement still > > to be addressed. If the intention is to cover these remaining > > requirements in the protocol draft, we should perhaps get > > these in before considering adoption as a WG draft. > > > > John > > > > > -----Original Message----- > > > From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com] > > > Sent: 20 January 2011 09:08 > > > To: Elwell, John; siprec@ietf.org > > > Subject: RE: [siprec] What happened to the 'recorded' feature tag? > > > > > > The intention for this draft is to include any extensions to address > > > recording-aware endpoints for the following requirements: > > > > > > REQ-15, 016, 017, 018 > > > > > > These requirements are currently not addressed in the > > protocol draft. > > > > > > Henry > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > > Behalf Of Elwell, John > > > > Sent: Thursday, January 20, 2011 3:26 AM > > > > To: siprec@ietf.org > > > > Subject: [siprec] What happened to the 'recorded' feature tag? > > > > > > > > Draft-johnston-siprec-cc-rec specified 3 media feature > > tags. Two of > > > > them, 'src' and 'srs', have been moved to draft-portman-siprec- > > > > protocol, as part of the merger of the two drafts. The third one, > > > > 'recorded', for use on the CS, has been dropped. I > > recognise this is > > > > not part of the "SIPREC protocol" between SRC and SRS, but > > > nevertheless > > > > it seems to be a solution to one of the SIPREC > > > requirements. What are > > > > the intentions of the draft authors? > > > > > > > > John > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > -------------------------------------------------------------- > > > ----------------------------------------------------- > > > CONFIDENTIALITY NOTICE: This e-mail and any files attached > > > may contain confidential and proprietary information of > > > Alcatel-Lucent and/or its affiliated entities. Access by the > > > intended recipient only is authorized. Any liability arising > > > from any party acting, or refraining from acting, on any > > > information contained in this e-mail is hereby excluded. If > > > you are not the intended recipient, please notify the sender > > > immediately, destroy the original transmission and its > > > attachments and do not disclose the contents to any other > > > person, use it for any purpose, or store or copy the > > > information in any medium. Copyright in this e-mail and any > > > attachments belongs to Alcatel-Lucent and/or its affiliated > > entities. > > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > > --001636c5b447420b34049a4885fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I thought the consensus of the group was that the notification requirements= were to be met by notifications in the media path.=A0

T= he fatal flaw with the feature tag approach was that it was not backwards c= ompatible - an RFC 3261 UA would not render or display this information to = the user, and hence some other notification would be needed.

We can certainly add it back in if the working group th= inks it is useful.

- Alan -

On Thu, Jan 20, 2011 at 8:22 AM, Hutton, Andrew <andrew.hutto= n@siemens-enterprise.com> wrote:
Hi All,

Hi all with regard to the 'recorded' feature tag them I don't k= now why this was not copied to the new draft I think it should have been. A= lan can you please comment on that.

We did update the scope in the 02 draft to make it clear that the protocol = specified also impacted the CS and this was I think because of the 'rec= orded' feature tag.

I suggest we put it back in at the next update.

Regards
Andy






> -----Original Message-----
> From: siprec-bounces@ietf.o= rg
> [mailto:siprec-bounces@ietf= .org] On Behalf Of Elwell, John
> Sent: 20 January 2011 09:33 > To: Henry Lum; siprec@ietf.org<= br> > Subject: Re: [siprec] What happened to the 'recorded' feature = tag?
>
> Henry,
>
> Thanks for the clarification. The particular requirement I
> picked on (REQ-018) is indeed not the only requirement still
> to be addressed. If the intention is to cover these remaining
> requirements in the protocol draft, we should perhaps get
> these in before considering adoption as a WG draft.
>
> John
>
> > -----Original Message-----
> > From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com]
> > Sent: 20 January 2011 09:08
> > To: Elwell, John; siprec@ietf.= org
> > Subject: RE: [siprec] What happened to the 'recorded' fea= ture tag?
> >
> > The intention for this draft is to include any extensions to addr= ess
> > recording-aware endpoints for the following requirements:
> >
> > REQ-15, 016, 017, 018
> >
> > These requirements are currently not addressed in the
> protocol draft.
> >
> > Henry
> >
> > > -----Original Message-----
> > > From: siprec-boun= ces@ietf.org [mailto:siprec-= bounces@ietf.org] On
> > > Behalf Of Elwell, John
> > > Sent: Thursday, January 20, 2011 3:26 AM
> > > To: siprec@ietf.org > > > Subject: [siprec] What happened to the 'recorded' fe= ature tag?
> > >
> > > Draft-johnston-siprec-cc-rec specified 3 media feature
> tags. Two of
> > > them, 'src' and 'srs', have been moved to dr= aft-portman-siprec-
> > > protocol, as part of the merger of the two drafts. The third= one,
> > > 'recorded', for use on the CS, has been dropped. I > recognise this is
> > > not part of the "SIPREC protocol" between SRC and = SRS, but
> > nevertheless
> > > it seems to be a solution to one of the SIPREC
> > requirements. What are
> > > the intentions of the draft authors?
> > >
> > > John
> > > _______________________________________________
> > > siprec mailing list
> > > siprec@ietf.org
> > > https://www.ietf.org/mailman/listinfo/siprec
> >
> >
> > -------------------------------------------------------------- > > -----------------------------------------------------
> > CONFIDENTIALITY NOTICE: This e-mail and any files attached
> > may contain confidential and proprietary information of
> > Alcatel-Lucent and/or its affiliated entities. Access by the
> > intended recipient only is authorized. Any liability arising
> > from any party acting, or refraining from acting, on any
> > information contained in this e-mail is hereby excluded. If
> > you are not the intended recipient, please notify the sender
> > immediately, destroy the original transmission and its
> > attachments and do not disclose the contents to any other
> > person, use it for any purpose, or store or copy the
> > information in any medium. Copyright in this e-mail and any
> > attachments belongs to Alcatel-Lucent and/or its affiliated
> entities.
> >
> >
> _______________________________________________
> siprec mailing list
> siprec@ietf.org
> https://www.ietf.org/mailman/listinfo/siprec
>

--001636c5b447420b34049a4885fe-- From andrew.hutton@siemens-enterprise.com Thu Jan 20 08:10:43 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2CB03A715B for ; Thu, 20 Jan 2011 08:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUpZAPLgbnQH for ; Thu, 20 Jan 2011 08:10:40 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id F368E3A7155 for ; Thu, 20 Jan 2011 08:10:38 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3086482; Thu, 20 Jan 2011 17:13:20 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id A1A5D1EB82AB; Thu, 20 Jan 2011 17:13:20 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 20 Jan 2011 17:13:21 +0100 From: "Hutton, Andrew" To: Alan Johnston Date: Thu, 20 Jan 2011 17:13:27 +0100 Thread-Topic: [siprec] What happened to the 'recorded' feature tag? Thread-Index: Acu4tAuKmarEAZLbTAWXa6Je/bIFyQACJdzw Message-ID: <101C6067BEC68246B0C3F6843BCCC1E30ABAA9C2DF@MCHP058A.global-ad.net> References: <059AF07365DC474393A19A3AF187DF7406904BD3@NAHALD.us.int.genesyslab.com> <101C6067BEC68246B0C3F6843BCCC1E30ABAA9C1E0@MCHP058A.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_101C6067BEC68246B0C3F6843BCCC1E30ABAA9C2DFMCHP058Agloba_" MIME-Version: 1.0 Cc: Henry Lum , "siprec@ietf.org" Subject: Re: [siprec] What happened to the 'recorded' feature tag? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 16:10:43 -0000 --_000_101C6067BEC68246B0C3F6843BCCC1E30ABAA9C2DFMCHP058Agloba_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My thinking has always been that we should include a recorded indication in= the CS and I think the charter actually refers to this. Obviously this might need to be backed up with an indication in the media p= ath but I don't see that as a reason for not including the information in S= IP. Regards Andy ________________________________ From: Alan Johnston [mailto:alan.b.johnston@gmail.com] Sent: 20 January 2011 15:10 To: Hutton, Andrew Cc: Elwell, John; Henry Lum; siprec@ietf.org Subject: Re: [siprec] What happened to the 'recorded' feature tag? I thought the consensus of the group was that the notification requirements= were to be met by notifications in the media path. The fatal flaw with the feature tag approach was that it was not backwards = compatible - an RFC 3261 UA would not render or display this information to= the user, and hence some other notification would be needed. We can certainly add it back in if the working group thinks it is useful. - Alan - On Thu, Jan 20, 2011 at 8:22 AM, Hutton, Andrew > wrote: Hi All, Hi all with regard to the 'recorded' feature tag them I don't know why this= was not copied to the new draft I think it should have been. Alan can you = please comment on that. We did update the scope in the 02 draft to make it clear that the protocol = specified also impacted the CS and this was I think because of the 'recorde= d' feature tag. I suggest we put it back in at the next update. Regards Andy > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behal= f Of Elwell, John > Sent: 20 January 2011 09:33 > To: Henry Lum; siprec@ietf.org > Subject: Re: [siprec] What happened to the 'recorded' feature tag? > > Henry, > > Thanks for the clarification. The particular requirement I > picked on (REQ-018) is indeed not the only requirement still > to be addressed. If the intention is to cover these remaining > requirements in the protocol draft, we should perhaps get > these in before considering adoption as a WG draft. > > John > > > -----Original Message----- > > From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com] > > Sent: 20 January 2011 09:08 > > To: Elwell, John; siprec@ietf.org > > Subject: RE: [siprec] What happened to the 'recorded' feature tag? > > > > The intention for this draft is to include any extensions to address > > recording-aware endpoints for the following requirements: > > > > REQ-15, 016, 017, 018 > > > > These requirements are currently not addressed in the > protocol draft. > > > > Henry > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto= :siprec-bounces@ietf.org] On > > > Behalf Of Elwell, John > > > Sent: Thursday, January 20, 2011 3:26 AM > > > To: siprec@ietf.org > > > Subject: [siprec] What happened to the 'recorded' feature tag? > > > > > > Draft-johnston-siprec-cc-rec specified 3 media feature > tags. Two of > > > them, 'src' and 'srs', have been moved to draft-portman-siprec- > > > protocol, as part of the merger of the two drafts. The third one, > > > 'recorded', for use on the CS, has been dropped. I > recognise this is > > > not part of the "SIPREC protocol" between SRC and SRS, but > > nevertheless > > > it seems to be a solution to one of the SIPREC > > requirements. What are > > > the intentions of the draft authors? > > > > > > John > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > -------------------------------------------------------------- > > ----------------------------------------------------- > > CONFIDENTIALITY NOTICE: This e-mail and any files attached > > may contain confidential and proprietary information of > > Alcatel-Lucent and/or its affiliated entities. Access by the > > intended recipient only is authorized. Any liability arising > > from any party acting, or refraining from acting, on any > > information contained in this e-mail is hereby excluded. If > > you are not the intended recipient, please notify the sender > > immediately, destroy the original transmission and its > > attachments and do not disclose the contents to any other > > person, use it for any purpose, or store or copy the > > information in any medium. Copyright in this e-mail and any > > attachments belongs to Alcatel-Lucent and/or its affiliated > entities. > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > --_000_101C6067BEC68246B0C3F6843BCCC1E30ABAA9C2DFMCHP058Agloba_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
My thinking has always been that we should include= a=20 recorded indication in the CS and I think the charter actually refers to=20 this.
 
Obviously this might need to be backed up with an= =20 indication in the media path but I don't see that as a reason for not inclu= ding=20 the information in SIP.
 
Regards
Andy
 
 
From: Alan = Johnston=20 [mailto:alan.b.johnston@gmail.com]
Sent: 20 January 2011=20 15:10
To: Hutton, Andrew
Cc: Elwell, John; Henry Lum;=20 siprec@ietf.org
Subject: Re: [siprec] What happened to the 'recor= ded'=20 feature tag?

I thought the consensus of the group was that the notification= =20 requirements were to be met by notifications in the media path. 

The fatal flaw with the feature tag approach was that it was not=20 backwards compatible - an RFC 3261 UA would not render or display this=20 information to the user, and hence some other notification would be=20 needed.

We can certainly add it back in if the working group thinks it is=20 useful.

- Alan -

On Thu, Jan 20, 2011 at 8:22 AM, Hutton, Andrew = <andrew.hutton@siemen= s-enterprise.com>=20 wrote:
Hi=20 All,

Hi all with regard to the 'recorded' feature tag them I don= 't=20 know why this was not copied to the new draft I think it should have be= en.=20 Alan can you please comment on that.

We did update the scope in = the=20 02 draft to make it clear that the protocol specified also impacted the= CS=20 and this was I think because of the 'recorded' feature tag.

I su= ggest=20 we put it back in at the next update.

Regards
Andy






> -----Original=20 Message-----
> From: siprec-bounces@ietf.org
= >=20 [mailto:siprec-bounces@ietf.org] On= Behalf=20 Of Elwell, John
> Sent: 20 January 2011 09:33
> To: Henry Lum;= siprec@ietf.org
> Subject: Re= :=20 [siprec] What happened to the 'recorded' feature tag?
>
>=20 Henry,
>
> Thanks for the clarification. The particular=20 requirement I
> picked on (REQ-018) is indeed not the only requir= ement=20 still
> to be addressed. If the intention is to cover these=20 remaining
> requirements in the protocol draft, we should perhaps= =20 get
> these in before considering adoption as a WG=20 draft.
>
> John
>
> > -----Original=20 Message-----
> > From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.c= om]
>=20 > Sent: 20 January 2011 09:08
> > To: Elwell, John; siprec@ietf.org
> > Subjec= t: RE:=20 [siprec] What happened to the 'recorded' feature tag?
> >
&= gt;=20 > The intention for this draft is to include any extensions to=20 address
> > recording-aware endpoints for the following=20 requirements:
> >
> > REQ-15, 016, 017, 018
>=20 >
> > These requirements are currently not addressed in=20 the
> protocol draft.
> >
> > Henry
>=20 >
> > > -----Original Message-----
> > > Fro= m: siprec-bounces@ietf.org [ma= ilto:siprec-bounces@ietf.org]=20 On
> > > Behalf Of Elwell, John
> > > Sent:=20 Thursday, January 20, 2011 3:26 AM
> > > To: siprec@ietf.org
> > > S= ubject:=20 [siprec] What happened to the 'recorded' feature tag?
> >=20 >
> > > Draft-johnston-siprec-cc-rec specified 3 media=20 feature
> tags. Two of
> > > them, 'src' and 'srs', h= ave=20 been moved to draft-portman-siprec-
> > > protocol, as part= of=20 the merger of the two drafts. The third one,
> > > 'recorde= d',=20 for use on the CS, has been dropped. I
> recognise this is
>= ;=20 > > not part of the "SIPREC protocol" between SRC and SRS, but>=20 > nevertheless
> > > it seems to be a solution to one of= the=20 SIPREC
> > requirements. What are
> > > the intent= ions=20 of the draft authors?
> > >
> > > John
> = >=20 > _______________________________________________
> > >= =20 siprec mailing list
> > > siprec@ietf.org
> > > <= A=20 href=3D"https://www.ietf.org/mailman/listinfo/siprec"=20 target=3D_blank>https://www.ietf.org/mailman/listinfo/siprec
>= ;=20 >
> >
> >=20 --------------------------------------------------------------
> = >=20 -----------------------------------------------------
> >=20 CONFIDENTIALITY NOTICE: This e-mail and any files attached
> >= may=20 contain confidential and proprietary information of
> >=20 Alcatel-Lucent and/or its affiliated entities. Access by the
> &g= t;=20 intended recipient only is authorized. Any liability arising
> &g= t;=20 from any party acting, or refraining from acting, on any
> >=20 information contained in this e-mail is hereby excluded. If
> >= ; you=20 are not the intended recipient, please notify the sender
> >=20 immediately, destroy the original transmission and its
> >=20 attachments and do not disclose the contents to any other
> >= =20 person, use it for any purpose, or store or copy the
> >=20 information in any medium. Copyright in this e-mail and any
> >= ;=20 attachments belongs to Alcatel-Lucent and/or its affiliated
>=20 entities.
> >
> >
>=20 _______________________________________________
> siprec mailing= =20 list
> siprec@ietf.org
= > https://www.ietf.org/mailman/listinfo/siprec
>= ;=20

--_000_101C6067BEC68246B0C3F6843BCCC1E30ABAA9C2DFMCHP058Agloba_-- From Dave.d.Smith@genesyslab.com Fri Jan 21 09:57:59 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 669663A6A6D for ; Fri, 21 Jan 2011 09:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0Ek7HU+LNQM for ; Fri, 21 Jan 2011 09:57:57 -0800 (PST) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [198.49.180.223]) by core3.amsl.com (Postfix) with ESMTP id D2C2D3A6A57 for ; Fri, 21 Jan 2011 09:57:57 -0800 (PST) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.wc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id p0LI0gfv011251; Fri, 21 Jan 2011 10:00:42 -0800 (PST) Received: from SARUMAN.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 21 Jan 2011 10:00:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Jan 2011 10:00:41 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Inputs to draft-ietf-siprec-req-06 Thread-Index: AcuyUfJnU/vECby9TGaM0uRbXItGhAC8g4WgABTj8SAAIgSUIAAANi2wAADxo7AABC4GcAAGsDKwACPaoVAAiivRkAAKrPkAAAA6kBAAEPRRwAAHdVJA References: <07465C1D981ABC41A344374066AE1A2C389F44872A@TLVMBX01.nice.com> From: "Dave Smith" To: "Leon Portman" , "Parthasarathi R (partr)" , "Elwell, John" , X-OriginalArrivalTime: 21 Jan 2011 18:00:43.0043 (UTC) FILETIME=[1EEEE730:01CBB995] X-Mailman-Approved-At: Fri, 21 Jan 2011 10:01:35 -0800 Subject: Re: [siprec] Inputs to draft-ietf-siprec-req-06 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 17:59:18 -0000 My follow-on inputs inline below ( [DS] ). Regards, Dave -----Original Message----- From: Leon Portman [mailto:Leon.Portman@nice.com]=20 Sent: Monday, January 17, 2011 11:13 PM To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org Cc: Dave Smith Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06 Looking good Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) Sent: Monday, January 17, 2011 4:35 PM To: Elwell, John; siprec@ietf.org Cc: Dave Smith Subject: Re: [siprec] Inputs to draft-ietf-siprec-req-06 John/David, I'm fine with REQ-5 as long as the intention is to avoid initial clipping in recording using persistent RS or similar SIPREC proposed mechanism. Just, I'm trying to reword for this requirement: o REQ-005 The mechanism MUST support the ability to record a CS without loss of media (for example, clipping media at the beginning of the CS) due to RS recording preparation and also, without impacting the quality or timing of the CS (for example, delaying the start of the CS while preparation for recording session). See Use Case 4 in Section 4 for more details.=20 --- Removed: "intentional" --- Added: "due to RS recording preparation and also" Please let me know your opinion. Thanks Partha -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Monday, January 17, 2011 4:31 PM To: Parthasarathi R (partr); siprec@ietf.org Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06 =20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 17 January 2011 09:09 > To: Elwell, John; siprec@ietf.org > Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06 >=20 > Please read inline >=20 > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Monday, January 17, 2011 2:08 PM > To: Elwell, John; siprec@ietf.org > Subject: Re: [siprec] Inputs to draft-ietf-siprec-req-06 >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: 17 January 2011 08:23 > > To: siprec@ietf.org > > Subject: [siprec] FW: Inputs to draft-ietf-siprec-req-06 > >=20 > > Forwarded on behalf of Dave Smith. > >=20 > > > -----Original Message----- > > > From: Dave Smith [mailto:Dave.Smith@genesyslab.com] > > > Sent: 16 January 2011 16:08 > > > To: Elwell, John > > > Subject: FW: Inputs to draft-ietf-siprec-req-06 > > >=20 > > > Hi John, > > >=20 > > > Can you please send this email out to the "siprec@ietf.org" email=20= > > > address for me. > > > Our Genesys email server is failing to send emails out to > > that address > > > again (in the mean time I will try to get it fixed through our=20 > > > HelpDesk). > > >=20 > > > Thanks, > > > Dave > > >=20 > > >=20 > > > -----Original Message----- > > > From: Dave Smith > > > Sent: Saturday, January 15, 2011 10:59 PM > > > To: Elwell, John; siprec@ietf.org > > > Subject: Inputs to draft-ietf-siprec-req-06 > > >=20 > > > Here are my inputs to the latest draft-ietf-siprec-req-06. =20 > > >=20 > > >=20 > > > 1. Recommend to change this: > > > o REQ-005 The mechanism MUST support the ability to record a CS > > > without an intentional loss of media (for example,=20 > clipping media >=20 > > > at > > > the beginning of the CS) and without impacting the quality or=20= > > > timing > > > of the CS (for example, delaying the start of the CS while > > > preparation for recording takes place). See Use Case 4 in=20 > > > Section 5. > > >=20 > > > To this: > > > o REQ-005 The mechanism MUST support the ability to record a CS > > > without an unintentional loss of media (for example, > > clipping media > > > at > > > the beginning of the CS) and without impacting the quality or=20= > > > timing > > > of the CS (for example, delaying the start of the CS while > > > preparation for recording takes place). =20 > > >=20 > > > The use case is not referenced correctly and I don't see > > any reason to > > > refer to it (doesn't provide much additional info). Also=20 > corrected=20 > > > "intentional" to "unintentional." > [JRE] The word "intentional" came from me a few months ago. Perhaps it > was the wrong word - I was trying to convey the fact that=20 > some mechanism > might frequently lead to clipping - the loss of media is kind of built > into the mechanism, so in that sense it would be=20 > "intentional". I don't > think changing to "unintentional" is correct - we can't avoid > unintentional loss of media, e.g., through packet loss. I=20 > guess what we > are really trying to achieve is something like this: "The=20 > mechanism MUST > support the ability to record a CS without loss of media while > preparation for recording takes place." >=20 > IMO, without any loss of media may lead to inefficient system > in few deployment. For example, CS dialog is established whereas RS is > taking more time to establish due to network delay between=20 > SRC and SRS, > then it may be preferred in few deployment to loss some media=20 > instead of > delaying CS establishment and some other deployment may prefer to wait > for RS establishment. The current requirement wording=20 > indicates that CS > dialog establishment MUST be delayed for RS establishment. =20= [JRE] No, I believe it was not intended to force the CS to be delayed. A mechanism that would meet this requirement without delaying CS establishment would be to keep an RS permanently established, even when there is no CS, so that it can immediately be used when a new CS starts. This was the persistent recording use case (4), which I believe some people felt was needed for some environments, and hence the desire to capture requirements that such environments have. Clearly we have failed to capture that requirements adequately - we need the right words. John (as individual) [DS] =20 I agree with John's new wording, and that for this document we should simplify and state: o REQ-005 "The mechanism MUST support the ability to record a CS without loss of RS media while preparation for recording takes place." Although in a future version we might want to consider this area further. =20 [DS] > > >=20 > > > 2. Recommend to change this: > > > o REQ-018 The mechanism MUST provide a means of > indicating to the > > > participants involved in a CS that their session is > > being recorded. > > >=20 > > > Examples include: inject tones into the CS from the SRC, play a > > > message at the beginning of a session, a visual indicator on a > > > display, etc. > > >=20 > > > To this: > > > o REQ-018 The mechanism MUST provide a means of=20 > indicating to the > > > participants involved in a CS that their session is > > currently being > > > recorded. > > >=20 > > > Examples include: inject tones into the CS from the=20 > SRC, a visual >=20 > > > indicator on a display > > >=20 > > > Added word "currently" because this is about providing an ongoing=20= > > > indicator during the call. Removed the "play a message...." part=20= > > > because playing a message at the beginning of a session is not a=20= > > > method that would require a siprec protocol solution,=20 > it's n/a, it's >=20 > > > not about " an ongoing indicator." > [JRE] The word "currently" was there, in my opinion, because playing a > message to indicate that recording might take place at some=20 > stage during > the CS is what frequently happens and is sufficient for regulatory > purposes in some jurisdictions. I agree it would not require a SIPREC > protocol solution. Let's see what others say. > I agree with John that playing a message meet some of the > Jurisdictions requirement. I like to hear from Dave whether any > jurisdiction mandates for "injection tone" or "visual display". > >=20 [DS] I believe that informing ahead of time (that is, to indicate that recording might take place at some stage during the CS) has nothing to do with SIPREC. If that is a suitable solution for this req't then I believe we should drop the req't entirely. =20 However, I see two reasons for functionality indicating that recording is "currently" going on. And although I do not know of any regulations requiring this functionality, I believe it is important. The reasons are: In order to inform (1) agents, and/or (2) customers that a call is "currently" being recorded. =20 For many Customers, I believe that playing a message up-front via an IVR (for example) to "inform" them that "a call may be recorded..." may not be enough and that it would be desirable to also provide an ongoing indicator if recording is actually occurring "currently." Also, there are many examples where companies/environments want to be able to inform their Agents when a call is "currently being recorded". [DS] =20 > Thanks > Partha >=20 > John (as individual) >=20 > > >=20 > > >=20 > > > 3. Recommend to change this: > > > o REQ-013 The mechanism MUST provide the SRS with the means to > > > correlate RS media with CS participant media described > > in metadata. > > >=20 > > > To this: > > > o REQ-013 The mechanism MUST provide the SRS with the means to > > > correlate RS media with CS participant media. > > >=20 > > > This is recommended because I don't see the need for the=20 > part that=20 > > > read "described in metadata" and because it is not clear what it=20= > > > meant. > > >=20 =20 [DS] I recommend to drop the wording "described in metadata" in REQ-013. [DS] > > >=20 > > > 4. Recommend to delete this Requirement: > > > o REQ-021 The mechanism MUST support means to relate Recording > > > Session(s) with Communication Session(s). > > >=20 > > > It is not needed since we have REQ-012 and REQ-013. =20 > > > [DS] I recommend to delete REQ-021. [DS] > > >=20 > > >=20 > > > Regards, > > > Dave > > >=20 > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > > Sent: Wednesday, January 12, 2011 4:12 AM > > > To: siprec@ietf.org > > > Subject: [siprec] Agenda requests plus reminder > > >=20 > > > Please let me have your agenda requests for the dual interim on=20 > > > 25th/26th. > > >=20 > > > Also, a reminder that WGLC on siprec-req is into its second > > week and I > > > have not seen any responses yet. Even if you are happy with it as=20= > > > is, a note to the list would be helpful. > > >=20 > > > John > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > >=20 > > > =09 > > > -------------------------------------------------------------- > > > ---------- > > > ------------------------------------------- > > > CONFIDENTIALITY NOTICE: This e-mail and any files attached > > may contain > > > confidential and proprietary information of Alcatel-Lucent > > and/or its > > > affiliated entities. Access by the intended recipient only is=20 > > > authorized. Any liability arising from any party acting, or > > refraining > > > from acting, on any information contained in this e-mail=20 > is hereby=20 > > > excluded. If you are not the intended recipient, please=20 > notify the=20 > > > sender immediately, destroy the original transmission and its=20 > > > attachments and do not disclose the contents to any other person,=20= > > > use it for any purpose, or store or copy the information in any=20 > > > medium. > > > Copyright in this e-mail and any attachments belongs to > > Alcatel-Lucent > > > and/or its affiliated entities. > > > =09 > > >=20 > > > =09 > > > -------------------------------------------------------------- > > > ----------------------------------------------------- > > > CONFIDENTIALITY NOTICE: This e-mail and any files attached may=20 > > > contain confidential and proprietary information of=20 > Alcatel-Lucent=20 > > > and/or its affiliated entities. Access by the intended recipient=20= > > > only is authorized. Any liability arising from any party=20 > acting, or=20 > > > refraining from acting, on any information contained in=20 > this e-mail=20 > > > is hereby excluded. If you are not the intended recipient, please=20= > > > notify the sender immediately, destroy the original=20 > transmission and >=20 > > > its attachments and do not disclose the contents to any other=20 > > > person, use it for any purpose, or store or copy the=20 > information in=20 > > > any medium. Copyright in this e-mail and any attachments=20 > belongs to=20 > > > Alcatel-Lucent and/or its affiliated > > entities. > > > =09 > > >=20 > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >=20 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From partr@cisco.com Fri Jan 21 10:39:19 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68E653A6A81 for ; Fri, 21 Jan 2011 10:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.442 X-Spam-Level: X-Spam-Status: No, score=-9.442 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKXbpQE8z88n for ; Fri, 21 Jan 2011 10:39:18 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DDE763A6A5F for ; Fri, 21 Jan 2011 10:39:17 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEDAL9iOU2Q/khLgWdsb2JhbACkBWEVAQEWIiSiDpsPhVAEhG2JXQ Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 21 Jan 2011 18:41:54 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p0LIfrDl021084 for ; Fri, 21 Jan 2011 18:41:53 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 22 Jan 2011 00:11:52 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBB99A.DED7D330" Date: Sat, 22 Jan 2011 00:11:52 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ram-siprec-metadata-format-00 for Review Thread-Index: Acu5mQo4RC5BhuXCQFOzg3WgV44EjAAABm26 References: <20110121182547.848C43A6A80@core3.amsl.com> From: "Parthasarathi R (partr)" To: X-OriginalArrivalTime: 21 Jan 2011 18:41:52.0505 (UTC) FILETIME=[DED8E690:01CBB99A] Subject: [siprec] draft-ram-siprec-metadata-format-00 for Review X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 18:39:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBB99A.DED7D330 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 Paul, Ram and myself have posted the initial Metadata format -00 draft = based on Metadata model draft(draft-ram-siprec-metadata). Metadata = format introduces new SIPREC metadata specific XML document and links to = SDP for media parameters. The draft provides realization of Metadata = model. =20 This draft is in initial stage with lot of open item. The basic idea of = posting this draft is to get the high level consensus, start the = discussion on interim meeting before deep dive into individual items. =20 Thanks Partha ________________________________ From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Fri 1/21/2011 11:55 PM To: Parthasarathi R (partr) Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) Subject: New Version Notification for = draft-ram-siprec-metadata-format-00=20 A new version of I-D, draft-ram-siprec-metadata-format-00.txt has been = successfully submitted by Parthasarathi R and posted to the IETF = repository. Filename: draft-ram-siprec-metadata-format Revision: 00 Title: Session Initiation Protocol (SIP) Recording Metadata = Format Creation_date: 2011-01-21 WG ID: Independent Submission Number_of_pages: 14 Abstract: 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. The requirements for which are described in [I-D.ietf-siprec-req], the architecture for which is described in [I-D.ietf-siprec-architecture], and the metadata model viewed by Session Recording Server is described in [I-D.ram-siprec-metadata]. This document focuses on the Recording metadata format which describes the communication session. = =20 The IETF Secretariat. ------_=_NextPart_001_01CBB99A.DED7D330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable New Version Notification for = draft-ram-siprec-metadata-format-00=0A= =0A= =0A= =0A=
=0A=
Hi = all,
=0A=
 
=0A=
Paul, Ram and = myself have posted the initial Metadata format -00 draft based on = Metadata model draft(draft-ram-siprec-metadata). Metadata format = introduces new SIPREC metadata specific XML document and links to SDP = for media parameters. The draft provides realization of Metadata = model.
=0A=
 
=0A=
This draft is in initial = stage with lot of open item. The basic idea of posting this draft is to = get the high level consensus, start the discussion on interim = meeting before deep dive into individual items.
=0A=
 
=0A=
Thanks
=0A=
Partha
=0A=

=0A=
=0A= From: IETF I-D Submission Tool = [mailto:idsubmission@ietf.org]
Sent: Fri 1/21/2011 11:55 = PM
To: Parthasarathi R (partr)
Cc: Ram Mohan R = (rmohanr); Paul Kyzivat (pkyzivat)
Subject: New Version = Notification for draft-ram-siprec-metadata-format-00 =

=0A=

=0A=

A new version of I-D, = draft-ram-siprec-metadata-format-00.txt has been successfully submitted = by Parthasarathi R and posted to the IETF = repository.

Filename:        = draft-ram-siprec-metadata-format
Revision:    &nbs= p;   00
Title:  =          Session Initiation = Protocol (SIP) Recording Metadata Format
Creation_date:   = 2011-01-21
WG ID:  =          Independent = Submission
Number_of_pages: 14

Abstract:
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.  The requirements for which are described = in
[I-D.ietf-siprec-req], the architecture for which is described = in
[I-D.ietf-siprec-architecture], and the metadata model viewed = by
Session Recording Server is described in = [I-D.ram-siprec-metadata].
This document focuses on the Recording = metadata format which
describes the communication = session.
          &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =           


T= he IETF Secretariat.


------_=_NextPart_001_01CBB99A.DED7D330-- From john.elwell@siemens-enterprise.com Sun Jan 23 23:55:07 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BF793A6955 for ; Sun, 23 Jan 2011 23:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhSi-2d2SF+Y for ; Sun, 23 Jan 2011 23:55:04 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 5996D28C0D6 for ; Sun, 23 Jan 2011 23:55:03 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3105943; Mon, 24 Jan 2011 08:57:53 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id B3F4323F0278; Mon, 24 Jan 2011 08:57:53 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 24 Jan 2011 08:57:53 +0100 From: "Elwell, John" To: Dave Smith , Leon Portman , "Parthasarathi R (partr)" , "siprec@ietf.org" Date: Mon, 24 Jan 2011 08:57:51 +0100 Thread-Topic: [siprec] Inputs to draft-ietf-siprec-req-06 Thread-Index: AcuyUfJnU/vECby9TGaM0uRbXItGhAC8g4WgABTj8SAAIgSUIAAANi2wAADxo7AABC4GcAAGsDKwACPaoVAAiivRkAAKrPkAAAA6kBAAEPRRwAAHdVJAAIHQnrA= Message-ID: References: <07465C1D981ABC41A344374066AE1A2C389F44872A@TLVMBX01.nice.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Inputs to draft-ietf-siprec-req-06 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 07:55:07 -0000 OK with me. John (as individual) > -----Original Message----- > From: Dave Smith [mailto:Dave.d.Smith@genesyslab.com] > Sent: 21 January 2011 18:01 > To: Leon Portman; Parthasarathi R (partr); Elwell, John; > siprec@ietf.org > Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06 > > > My follow-on inputs inline below ( [DS] ). > > Regards, > Dave > > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: Monday, January 17, 2011 11:13 PM > To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > Cc: Dave Smith > Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06 > > Looking good > > Leon > > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf > Of Parthasarathi R (partr) > Sent: Monday, January 17, 2011 4:35 PM > To: Elwell, John; siprec@ietf.org > Cc: Dave Smith > Subject: Re: [siprec] Inputs to draft-ietf-siprec-req-06 > > John/David, > > I'm fine with REQ-5 as long as the intention is to avoid initial > clipping in recording using persistent RS or similar SIPREC proposed > mechanism. Just, I'm trying to reword for this requirement: > > o REQ-005 The mechanism MUST support the ability to record a > CS without > loss of media (for example, clipping media at the beginning of the CS) > due to RS recording preparation and also, without impacting > the quality > or timing of the CS (for example, delaying the start of the CS while > preparation for recording session). See Use Case 4 in Section > 4 for more > details. > > --- Removed: "intentional" > --- Added: "due to RS recording preparation and also" > > Please let me know your opinion. > > Thanks > Partha > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Monday, January 17, 2011 4:31 PM > To: Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06 > > > > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 17 January 2011 09:09 > > To: Elwell, John; siprec@ietf.org > > Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06 > > > > Please read inline > > > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: Monday, January 17, 2011 2:08 PM > > To: Elwell, John; siprec@ietf.org > > Subject: Re: [siprec] Inputs to draft-ietf-siprec-req-06 > > > > > > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > > Sent: 17 January 2011 08:23 > > > To: siprec@ietf.org > > > Subject: [siprec] FW: Inputs to draft-ietf-siprec-req-06 > > > > > > Forwarded on behalf of Dave Smith. > > > > > > > -----Original Message----- > > > > From: Dave Smith [mailto:Dave.Smith@genesyslab.com] > > > > Sent: 16 January 2011 16:08 > > > > To: Elwell, John > > > > Subject: FW: Inputs to draft-ietf-siprec-req-06 > > > > > > > > Hi John, > > > > > > > > Can you please send this email out to the > "siprec@ietf.org" email > > > > address for me. > > > > Our Genesys email server is failing to send emails out to > > > that address > > > > again (in the mean time I will try to get it fixed through our > > > > HelpDesk). > > > > > > > > Thanks, > > > > Dave > > > > > > > > > > > > -----Original Message----- > > > > From: Dave Smith > > > > Sent: Saturday, January 15, 2011 10:59 PM > > > > To: Elwell, John; siprec@ietf.org > > > > Subject: Inputs to draft-ietf-siprec-req-06 > > > > > > > > Here are my inputs to the latest draft-ietf-siprec-req-06. > > > > > > > > > > > > 1. Recommend to change this: > > > > o REQ-005 The mechanism MUST support the ability to > record a CS > > > > without an intentional loss of media (for example, > > clipping media > > > > > > at > > > > the beginning of the CS) and without impacting the > quality or > > > > timing > > > > of the CS (for example, delaying the start of the CS while > > > > preparation for recording takes place). See Use Case 4 in > > > > Section 5. > > > > > > > > To this: > > > > o REQ-005 The mechanism MUST support the ability to > record a CS > > > > without an unintentional loss of media (for example, > > > clipping media > > > > at > > > > the beginning of the CS) and without impacting the > quality or > > > > timing > > > > of the CS (for example, delaying the start of the CS while > > > > preparation for recording takes place). > > > > > > > > The use case is not referenced correctly and I don't see > > > any reason to > > > > refer to it (doesn't provide much additional info). Also > > corrected > > > > "intentional" to "unintentional." > > [JRE] The word "intentional" came from me a few months ago. > Perhaps it > > was the wrong word - I was trying to convey the fact that > > some mechanism > > might frequently lead to clipping - the loss of media is > kind of built > > into the mechanism, so in that sense it would be > > "intentional". I don't > > think changing to "unintentional" is correct - we can't avoid > > unintentional loss of media, e.g., through packet loss. I > > guess what we > > are really trying to achieve is something like this: "The > > mechanism MUST > > support the ability to record a CS without loss of media while > > preparation for recording takes place." > > > > IMO, without any loss of media may lead to > inefficient system > > in few deployment. For example, CS dialog is established > whereas RS is > > taking more time to establish due to network delay between > > SRC and SRS, > > then it may be preferred in few deployment to loss some media > > instead of > > delaying CS establishment and some other deployment may > prefer to wait > > for RS establishment. The current requirement wording > > indicates that CS > > dialog establishment MUST be delayed for RS establishment. > > [JRE] No, I believe it was not intended to force the CS to be > delayed. A > mechanism that would meet this requirement without delaying CS > establishment would be to keep an RS permanently established, > even when > there is no CS, so that it can immediately be used when a new > CS starts. > This was the persistent recording use case (4), which I believe some > people felt was needed for some environments, and hence the desire to > capture requirements that such environments have. Clearly we > have failed > to capture that requirements adequately - we need the right words. > > John (as individual) > > [DS] > I agree with John's new wording, and that for this document we should > simplify and state: o REQ-005 "The mechanism MUST support > the ability > to record a CS without loss of RS media while preparation for > recording > takes place." > Although in a future version we might want to consider this area > further. > [DS] > > > > > > > > > 2. Recommend to change this: > > > > o REQ-018 The mechanism MUST provide a means of > > indicating to the > > > > participants involved in a CS that their session is > > > being recorded. > > > > > > > > Examples include: inject tones into the CS from the > SRC, play a > > > > message at the beginning of a session, a visual > indicator on a > > > > display, etc. > > > > > > > > To this: > > > > o REQ-018 The mechanism MUST provide a means of > > indicating to the > > > > participants involved in a CS that their session is > > > currently being > > > > recorded. > > > > > > > > Examples include: inject tones into the CS from the > > SRC, a visual > > > > > > indicator on a display > > > > > > > > Added word "currently" because this is about providing > an ongoing > > > > indicator during the call. Removed the "play a > message...." part > > > > because playing a message at the beginning of a session > is not a > > > > method that would require a siprec protocol solution, > > it's n/a, it's > > > > > > not about " an ongoing indicator." > > [JRE] The word "currently" was there, in my opinion, > because playing a > > message to indicate that recording might take place at some > > stage during > > the CS is what frequently happens and is sufficient for regulatory > > purposes in some jurisdictions. I agree it would not > require a SIPREC > > protocol solution. Let's see what others say. > > I agree with John that playing a message meet some of the > > Jurisdictions requirement. I like to hear from Dave whether any > > jurisdiction mandates for "injection tone" or "visual display". > > > > > [DS] I believe that informing ahead of time (that is, to > indicate that > recording might take place at some stage during the CS) has nothing to > do with SIPREC. If that is a suitable solution for this req't then I > believe we should drop the req't entirely. > However, I see two reasons for functionality indicating that recording > is "currently" going on. And although I do not know of any > regulations > requiring this functionality, I believe it is important. The reasons > are: In order to inform (1) agents, and/or (2) customers > that a call is > "currently" being recorded. > For many Customers, I believe that playing a message up-front > via an IVR > (for example) to "inform" them that "a call may be > recorded..." may not > be enough and that it would be desirable to also provide an ongoing > indicator if recording is actually occurring "currently." > Also, there > are many examples where companies/environments want to be > able to inform > their Agents when a call is "currently being recorded". [DS] > > > > Thanks > > Partha > > > > John (as individual) > > > > > > > > > > > > > > 3. Recommend to change this: > > > > o REQ-013 The mechanism MUST provide the SRS with > the means to > > > > correlate RS media with CS participant media described > > > in metadata. > > > > > > > > To this: > > > > o REQ-013 The mechanism MUST provide the SRS with > the means to > > > > correlate RS media with CS participant media. > > > > > > > > This is recommended because I don't see the need for the > > part that > > > > read "described in metadata" and because it is not > clear what it > > > > meant. > > > > > > [DS] I recommend to drop the wording "described in metadata" in > REQ-013. [DS] > > > > > > > > > 4. Recommend to delete this Requirement: > > > > o REQ-021 The mechanism MUST support means to relate > Recording > > > > Session(s) with Communication Session(s). > > > > > > > > It is not needed since we have REQ-012 and REQ-013. > > > > > [DS] I recommend to delete REQ-021. [DS] > > > > > > > > > > > > Regards, > > > > Dave > > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > > > Sent: Wednesday, January 12, 2011 4:12 AM > > > > To: siprec@ietf.org > > > > Subject: [siprec] Agenda requests plus reminder > > > > > > > > Please let me have your agenda requests for the dual interim on > > > > 25th/26th. > > > > > > > > Also, a reminder that WGLC on siprec-req is into its second > > > week and I > > > > have not seen any responses yet. Even if you are happy > with it as > > > > is, a note to the list would be helpful. > > > > > > > > John > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > -------------------------------------------------------------- > > > > ---------- > > > > ------------------------------------------- > > > > CONFIDENTIALITY NOTICE: This e-mail and any files attached > > > may contain > > > > confidential and proprietary information of Alcatel-Lucent > > > and/or its > > > > affiliated entities. Access by the intended recipient only is > > > > authorized. Any liability arising from any party acting, or > > > refraining > > > > from acting, on any information contained in this e-mail > > is hereby > > > > excluded. If you are not the intended recipient, please > > notify the > > > > sender immediately, destroy the original transmission and its > > > > attachments and do not disclose the contents to any > other person, > > > > use it for any purpose, or store or copy the information in any > > > > medium. > > > > Copyright in this e-mail and any attachments belongs to > > > Alcatel-Lucent > > > > and/or its affiliated entities. > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > ----------------------------------------------------- > > > > CONFIDENTIALITY NOTICE: This e-mail and any files attached may > > > > contain confidential and proprietary information of > > Alcatel-Lucent > > > > and/or its affiliated entities. Access by the intended > recipient > > > > only is authorized. Any liability arising from any party > > acting, or > > > > refraining from acting, on any information contained in > > this e-mail > > > > is hereby excluded. If you are not the intended > recipient, please > > > > notify the sender immediately, destroy the original > > transmission and > > > > > > its attachments and do not disclose the contents to any other > > > > person, use it for any purpose, or store or copy the > > information in > > > > any medium. Copyright in this e-mail and any attachments > > belongs to > > > > Alcatel-Lucent and/or its affiliated > > > entities. > > > > > > > > > > > _______________________________________________ > > > 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 > > > -------------------------------------------------------------- > ----------------------------------------------------- > CONFIDENTIALITY NOTICE: This e-mail and any files attached > may contain confidential and proprietary information of > Alcatel-Lucent and/or its affiliated entities. Access by the > intended recipient only is authorized. Any liability arising > from any party acting, or refraining from acting, on any > information contained in this e-mail is hereby excluded. If > you are not the intended recipient, please notify the sender > immediately, destroy the original transmission and its > attachments and do not disclose the contents to any other > person, use it for any purpose, or store or copy the > information in any medium. Copyright in this e-mail and any > attachments belongs to Alcatel-Lucent and/or its affiliated entities. > > From rajnish.jain@ipc.com Mon Jan 24 02:08:30 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7341C3A6A90 for ; Mon, 24 Jan 2011 02:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmVVlWPBTLCi for ; Mon, 24 Jan 2011 02:08:29 -0800 (PST) Received: from p01c12o147.mxlogic.net (p01c12o147.mxlogic.net [208.65.145.70]) by core3.amsl.com (Postfix) with ESMTP id 017D43A6A8F for ; Mon, 24 Jan 2011 02:08:28 -0800 (PST) Received: from unknown [65.244.37.51] (EHLO p01c12o147.mxlogic.net) by p01c12o147.mxlogic.net(mxl_mta-6.8.0-3) with ESMTP id b405d3d4.4ff12940.11586.00-585.22185.p01c12o147.mxlogic.net (envelope-from ); Mon, 24 Jan 2011 03:11:23 -0700 (MST) X-MXL-Hash: 4d3d504b083e64d8-380a77a1b11d4e057e38414ec2ab74b4da15ae78 Received: from unknown [65.244.37.51] by p01c12o147.mxlogic.net(mxl_mta-6.8.0-3) with SMTP id 6305d3d4.0.11469.00-396.22122.p01c12o147.mxlogic.net (envelope-from ); Mon, 24 Jan 2011 03:11:04 -0700 (MST) X-MXL-Hash: 4d3d5038526d0606-49b7bc159a7ffa1b7dceba71e8fffdac301f3867 Received: from STSNYCMS1.corp.root.ipc.com ([169.254.2.100]) by STSNYHTCAS1.corp.root.ipc.com ([10.201.40.92]) with mapi; Mon, 24 Jan 2011 05:10:55 -0500 From: "Jain, Rajnish" To: Henry Lum , "Elwell, John" , "siprec@ietf.org" Date: Mon, 24 Jan 2011 05:10:57 -0500 Thread-Topic: [siprec] Extension to WGLC for siprec-req Thread-Index: Acu3JYIeO0vv8RdvT36l5TlpmKsJ8wAub1TAAPPuB1A= Message-ID: References: <059AF07365DC474393A19A3AF187DF740690499F@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF740690499F@NAHALD.us.int.genesyslab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1307-6.500.1024-17912.004 x-tm-as-result: No--60.259700-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [65.244.37.51] X-AnalysisOut: [v=1.0 c=1 a=Vxill5Q5K7kA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel] X-AnalysisOut: [0A:10 a=z+2a4RCZxltofrpCDsS06w==:17 a=48vgC7mUAAAA:8 a=cg4] X-AnalysisOut: [j_VLt3_JRueDtpegA:9 a=trWrouOrX61Ha2Pwo9MA:7 a=zCZF_E2QGja] X-AnalysisOut: [V6I63aU_WlBVxqJ0A:4 a=CjuIK1q_8ugA:10 a=pPgXnZJf8G4A:10 a=] X-AnalysisOut: [lZB815dzVvQA:10 a=OIM2sFY21krqcccZ:21 a=zkjelGw8lHltI5zn:2] X-AnalysisOut: [1] Subject: Re: [siprec] Extension to WGLC for siprec-req X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 10:08:30 -0000 +1 ----------------------------------------------------- Please consider the environment before printing this email. > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Henry Lum > Sent: Wednesday, January 19, 2011 10:25 AM > To: Elwell, John; siprec@ietf.org > Subject: Re: [siprec] Extension to WGLC for siprec-req > > I have no comments and I am okay with the draft. > > Henry > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > > Sent: Tuesday, January 18, 2011 10:37 AM > > To: siprec@ietf.org > > Subject: [siprec] Extension to WGLC for siprec-req > > > > There was a disappointingly poor response to WGLC, which ended > > yesterday. Therefore the chairs have decided to extend WGLC until > next > > Monday, 2011-01-24 (i.e., to finish the day before the interim > virtual > > meeting). Please submit your comments and/or indicate whether you > > consider the document ready to go by that date. > > > > John > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > > ----------------------------------------------------------------------- > -------------------------------------------- > CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain > confidential and proprietary information of Alcatel-Lucent and/or its > affiliated entities. Access by the intended recipient only is > authorized. Any liability arising from any party acting, or refraining > from acting, on any information contained in this e-mail is hereby > excluded. If you are not the intended recipient, please notify the > sender immediately, destroy the original transmission and its > attachments and do not disclose the contents to any other person, use > it for any purpose, or store or copy the information in any medium. > Copyright in this e-mail and any attachments belongs to Alcatel-Lucent > and/or its affiliated entities. > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec DISCLAIMER: This e-mail may contain information that is confidential, privi= leged or otherwise protected from disclosure. If you are not an intended re= cipient of this e-mail, do not duplicate or redistribute it by any means. P= lease delete it and any attachments and notify the sender that you have rec= eived it in error. Unintended recipients are prohibited from taking action = on the basis of information in this e-mail.E-mail messages may contain comp= uter viruses or other defects, may not be accurately replicated on other sy= stems, or may be intercepted, deleted or interfered with without the knowle= dge of the sender or the intended recipient. If you are not comfortable wit= h the risks associated with e-mail messages, you may decide not to use e-ma= il to communicate with IPC. IPC reserves the right, to the extent and under= circumstances permitted by applicable law, to retain, monitor and intercep= t e-mail messages to and from its systems. From Leon.Portman@nice.com Mon Jan 24 02:24:08 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 054253A681B for ; Mon, 24 Jan 2011 02:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+EW0dpAE1W2 for ; Mon, 24 Jan 2011 02:24:07 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id A40EA3A682E for ; Mon, 24 Jan 2011 02:24:06 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Mon, 24 Jan 2011 12:26:59 +0200 From: Leon Portman To: "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Date: Mon, 24 Jan 2011 12:26:58 +0200 Thread-Topic: [siprec] FW: New Version Notification for draft-ram-siprec-metadata-03 Thread-Index: Acu4WQQUW+MLpKTaTseJmyqbsa8uGAAAA+RQAM3rtyA= Message-ID: <07465C1D981ABC41A344374066AE1A2C389F5D1030@TLVMBX01.nice.com> References: <35BCE99A477D6A4986FB2216D8CF2CFD05024D77@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD05024D77@XMB-BGL-417.cisco.com> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] FW: New Version Notification for draft-ram-siprec-metadata-03 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 10:24:08 -0000 Ram, Hi Looking very good. My comments: 1. Section 4.3: Why do we still have Force Deletion in CS? You are stating= in the text that retention parameters are out of scope and can be reported= via AppData 2. Section 4.4 Participant. I still think that reporting of Participant rol= e (if it is known to SRC) like Initiator of the call, is very important 3. Section 5.2. I am not sure what do you mean by Pause/Resume from SRS to = SRC. To pause RS? Then there should be an event in the Metadata reporting s= ession (in case Metadata is reported outside RS) Regards Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Ram Mohan R (rmohanr) Sent: Thursday, January 20, 2011 6:20 AM To: siprec@ietf.org Subject: [siprec] FW: New Version Notification for draft-ram-siprec-metadat= a-03 Hi All, Submitted the next version of metadata model which has: - Updated Metadata model in Section 3. Now Media Stream block is directly c= onnected to CS along with participants. This is needed because a stream wit= h Zero participant will be hanging stream which will not be associated dire= ctly with CS. So we need explicit references between streams and CSs. (Link= ing them by participant isn't sufficient.) - Modified the draft with the comments closed ( on different attributes of = metamodel and the associations) during Dec 16th 2010 Interim meeting. - Updated the object instances to show the CS to Media Stream associations The new version of the draft is available at https://datatracker.ietf.org/d= oc/draft-ram-siprec-metadata/ Please review and provide your comments/inputs We will discuss more about the updates done to ver-03 during the interim me= eting next week. Regards, Ram -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Thursday, January 20, 2011 9:45 AM To: Ram Mohan R (rmohanr) Cc: Parthasarathi R (partr); Paul Kyzivat (pkyzivat) Subject: New Version Notification for draft-ram-siprec-metadata-03=20 A new version of I-D, draft-ram-siprec-metadata-03.txt has been successfull= y submitted by Ram R and posted to the IETF repository. Filename: draft-ram-siprec-metadata Revision: 03 Title: Session Initiation Protocol (SIP) Recording Metadata Creation_date: 2011-01-20 WG ID: Independent Submission Number_of_pages: 17 Abstract: 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 the metadata model as viewed by Session Recording Server(SRS). = =20 The IETF Secretariat. _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From Leon.Portman@nice.com Mon Jan 24 02:24:16 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C488F3A681B for ; Mon, 24 Jan 2011 02:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWdXCtcumkal for ; Mon, 24 Jan 2011 02:24:15 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id 779A43A6831 for ; Mon, 24 Jan 2011 02:24:14 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Mon, 24 Jan 2011 12:27:08 +0200 From: Leon Portman To: "Parthasarathi R (partr)" , "siprec@ietf.org" Date: Mon, 24 Jan 2011 12:27:06 +0200 Thread-Topic: draft-ram-siprec-metadata-format-00 for Review Thread-Index: Acu5mQo4RC5BhuXCQFOzg3WgV44EjAAABm26AH5aJ7A= Message-ID: <07465C1D981ABC41A344374066AE1A2C389F5D1032@TLVMBX01.nice.com> References: <20110121182547.848C43A6A80@core3.amsl.com> In-Reply-To: Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: multipart/alternative; boundary="_000_07465C1D981ABC41A344374066AE1A2C389F5D1032TLVMBX01nicec_" MIME-Version: 1.0 Subject: Re: [siprec] draft-ram-siprec-metadata-format-00 for Review X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 10:24:16 -0000 --_000_07465C1D981ABC41A344374066AE1A2C389F5D1032TLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Partha, Hi Thank you very much for posting. Following my comments: 1. Do we want also considering supporting light-weight formats like J= SON or compressed XML? 2. 4.2.3 SRS does not have any knowledge to generate group id. And it= is also supposed to be populated by the sender (SRC) 3. 4.2.11 It should be UTC time stamp, preferably with 10ms resolutio= n 4. I am still missing how we will report updates: like adding partici= pants or removing media streams. We should support sending only updates tup= ples and also indication if they were removed Regards Leon From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Parthasarathi R (partr) Sent: Friday, January 21, 2011 8:42 PM To: siprec@ietf.org Subject: [siprec] draft-ram-siprec-metadata-format-00 for Review Hi all, Paul, Ram and myself have posted the initial Metadata format -00 draft base= d on Metadata model draft(draft-ram-siprec-metadata). Metadata format intro= duces new SIPREC metadata specific XML document and links to SDP for media = parameters. The draft provides realization of Metadata model. This draft is in initial stage with lot of open item. The basic idea of pos= ting this draft is to get the high level consensus, start the discussion on= interim meeting before deep dive into individual items. Thanks Partha ________________________________ From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Fri 1/21/2011 11:55 PM To: Parthasarathi R (partr) Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) Subject: New Version Notification for draft-ram-siprec-metadata-format-00 A new version of I-D, draft-ram-siprec-metadata-format-00.txt has been succ= essfully submitted by Parthasarathi R and posted to the IETF repository. Filename: draft-ram-siprec-metadata-format Revision: 00 Title: Session Initiation Protocol (SIP) Recording Metadata Forma= t Creation_date: 2011-01-21 WG ID: Independent Submission Number_of_pages: 14 Abstract: 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. The requirements for which are described in [I-D.ietf-siprec-req], the architecture for which is described in [I-D.ietf-siprec-architecture], and the metadata model viewed by Session Recording Server is described in [I-D.ram-siprec-metadata]. This document focuses on the Recording metadata format which describes the communication session. The IETF Secretariat. --_000_07465C1D981ABC41A344374066AE1A2C389F5D1032TLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New Version Notification for draft-ram-siprec-me= tadata-format-00

Partha, H= i

 =

Thank you very much for posting. Following = my comments:

 

1.   &nb= sp;   Do we want also considering supporting light-weight formats like JSON or = compressed XML?

2.       4.2.3 SRS does not have any knowledge to generate g= roup id. And it is also supposed to be populated by the sender (SRC)

3.   &nb= sp;   4.2.11 It should be UTC time stamp, preferably with 10ms resolution<= /o:p>

4.   &n= bsp;   I am still missing how we will report updates: like adding participants = or removing media streams. We should support sending only updates tupples a= nd also indication if they were removed

Regards

 

Leon<= /p>

 

<= p class=3DMsoNormal>From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf= .org] On Behalf Of Parthasarathi R (partr)
Sent: Friday, J= anuary 21, 2011 8:42 PM
To: siprec@ietf.org
Subject: [s= iprec] draft-ram-siprec-metadata-format-00 for Review

=

 

Hi all,

 

Paul, R= am and myself have posted the initial Metadata format -00 draft based = on Metadata model draft(draft-ram-siprec-metadata). Metadata format introdu= ces new SIPREC metadata specific XML document and links to SDP for media pa= rameters. The draft provides realization of Metadata model.

 

This draft is in initial stage with lot of open item. The basic idea= of posting this draft is to get the high level consensus, start the discus= sion on interim meeting before deep dive into individual items.=

 

<= div>

Thanks

Partha

 =

From: IETF I-D Submission Tool [mailto:idsubmission@ietf= .org]
Sent: Fri 1/21/2011 11:55 PM
To: Parthasarathi R = (partr)
Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
= Subject: New Version Notification for draft-ram-siprec-metadata-format-= 00

 <= /p>

A new= version of I-D, draft-ram-siprec-metadata-format-00.txt has been successfu= lly submitted by Parthasarathi R and posted to the IETF repository.

= Filename:        draft-ram-siprec-metada= ta-format
Revision:        00
Titl= e:           Session Initiatio= n Protocol (SIP) Recording Metadata Format
Creation_date:   20= 11-01-21
WG ID:           I= ndependent Submission
Number_of_pages: 14

Abstract:
Session re= cording is a critical requirement in many communications
environments su= ch as call centers and financial trading.  In some of
these environ= ments, all calls must be recorded for regulatory,
compliance, and consum= er protection reasons.  Recording of a session
is typically perform= ed by sending a copy of a media stream to a
recording device.  The = requirements for which are described in
[I-D.ietf-siprec-req], the archi= tecture for which is described in
[I-D.ietf-siprec-architecture], and th= e metadata model viewed by
Session Recording Server is described in [I-D= .ram-siprec-metadata].
This document focuses on the Recording metadata f= ormat which
describes the communication session.
   &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;  


The IETF Secretariat.

=

= --_000_07465C1D981ABC41A344374066AE1A2C389F5D1032TLVMBX01nicec_-- From Leon.Portman@nice.com Mon Jan 24 02:24:21 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DC0B3A6836 for ; Mon, 24 Jan 2011 02:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRN-nTJk0ITp for ; Mon, 24 Jan 2011 02:24:19 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id 6AA873A6839 for ; Mon, 24 Jan 2011 02:24:18 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Mon, 24 Jan 2011 12:27:12 +0200 From: Leon Portman To: Dave Smith , "Parthasarathi R (partr)" , "Elwell, John" , "siprec@ietf.org" Date: Mon, 24 Jan 2011 12:27:10 +0200 Thread-Topic: [siprec] Inputs to draft-ietf-siprec-req-06 Thread-Index: AcuyUfJnU/vECby9TGaM0uRbXItGhAC8g4WgABTj8SAAIgSUIAAANi2wAADxo7AABC4GcAAGsDKwACPaoVAAiivRkAAKrPkAAAA6kBAAEPRRwAAHdVJAAIAdkFA= Message-ID: <07465C1D981ABC41A344374066AE1A2C389F5D1033@TLVMBX01.nice.com> References: <07465C1D981ABC41A344374066AE1A2C389F44872A@TLVMBX01.nice.com> In-Reply-To: Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Inputs to draft-ietf-siprec-req-06 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 10:24:21 -0000 Ok, Thank you Leon -----Original Message----- From: Dave Smith [mailto:Dave.d.Smith@genesyslab.com]=20 Sent: Friday, January 21, 2011 8:01 PM To: Leon Portman; Parthasarathi R (partr); Elwell, John; siprec@ietf.org Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06 My follow-on inputs inline below ( [DS] ). Regards, Dave -----Original Message----- From: Leon Portman [mailto:Leon.Portman@nice.com] Sent: Monday, January 17, 2011 11:13 PM To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org Cc: Dave Smith Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06 Looking good Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Parthasarathi R (partr) Sent: Monday, January 17, 2011 4:35 PM To: Elwell, John; siprec@ietf.org Cc: Dave Smith Subject: Re: [siprec] Inputs to draft-ietf-siprec-req-06 John/David, I'm fine with REQ-5 as long as the intention is to avoid initial clipping i= n recording using persistent RS or similar SIPREC proposed mechanism. Just,= I'm trying to reword for this requirement: o REQ-005 The mechanism MUST support the ability to record a CS without lo= ss of media (for example, clipping media at the beginning of the CS) due to= RS recording preparation and also, without impacting the quality or timing= of the CS (for example, delaying the start of the CS while preparation for= recording session). See Use Case 4 in Section 4 for more details.=20 --- Removed: "intentional" --- Added: "due to RS recording preparation and also" Please let me know your opinion. Thanks Partha -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] Sent: Monday, January 17, 2011 4:31 PM To: Parthasarathi R (partr); siprec@ietf.org Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06 =20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 17 January 2011 09:09 > To: Elwell, John; siprec@ietf.org > Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06 >=20 > Please read inline >=20 > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Monday, January 17, 2011 2:08 PM > To: Elwell, John; siprec@ietf.org > Subject: Re: [siprec] Inputs to draft-ietf-siprec-req-06 >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: 17 January 2011 08:23 > > To: siprec@ietf.org > > Subject: [siprec] FW: Inputs to draft-ietf-siprec-req-06 > >=20 > > Forwarded on behalf of Dave Smith. > >=20 > > > -----Original Message----- > > > From: Dave Smith [mailto:Dave.Smith@genesyslab.com] > > > Sent: 16 January 2011 16:08 > > > To: Elwell, John > > > Subject: FW: Inputs to draft-ietf-siprec-req-06 > > >=20 > > > Hi John, > > >=20 > > > Can you please send this email out to the "siprec@ietf.org" email=20 > > > address for me. > > > Our Genesys email server is failing to send emails out to > > that address > > > again (in the mean time I will try to get it fixed through our=20 > > > HelpDesk). > > >=20 > > > Thanks, > > > Dave > > >=20 > > >=20 > > > -----Original Message----- > > > From: Dave Smith > > > Sent: Saturday, January 15, 2011 10:59 PM > > > To: Elwell, John; siprec@ietf.org > > > Subject: Inputs to draft-ietf-siprec-req-06 > > >=20 > > > Here are my inputs to the latest draft-ietf-siprec-req-06. =20 > > >=20 > > >=20 > > > 1. Recommend to change this: > > > o REQ-005 The mechanism MUST support the ability to record a CS > > > without an intentional loss of media (for example, > clipping media >=20 > > > at > > > the beginning of the CS) and without impacting the quality or=20 > > > timing > > > of the CS (for example, delaying the start of the CS while > > > preparation for recording takes place). See Use Case 4 in=20 > > > Section 5. > > >=20 > > > To this: > > > o REQ-005 The mechanism MUST support the ability to record a CS > > > without an unintentional loss of media (for example, > > clipping media > > > at > > > the beginning of the CS) and without impacting the quality or=20 > > > timing > > > of the CS (for example, delaying the start of the CS while > > > preparation for recording takes place). =20 > > >=20 > > > The use case is not referenced correctly and I don't see > > any reason to > > > refer to it (doesn't provide much additional info). Also > corrected > > > "intentional" to "unintentional." > [JRE] The word "intentional" came from me a few months ago. Perhaps it=20 > was the wrong word - I was trying to convey the fact that some=20 > mechanism might frequently lead to clipping - the loss of media is=20 > kind of built into the mechanism, so in that sense it would be=20 > "intentional". I don't think changing to "unintentional" is correct -=20 > we can't avoid unintentional loss of media, e.g., through packet loss.=20 > I guess what we are really trying to achieve is something like this:=20 > "The mechanism MUST support the ability to record a CS without loss of=20 > media while preparation for recording takes place." >=20 > IMO, without any loss of media may lead to inefficient system=20 > in few deployment. For example, CS dialog is established whereas RS is=20 > taking more time to establish due to network delay between SRC and=20 > SRS, then it may be preferred in few deployment to loss some media=20 > instead of delaying CS establishment and some other deployment may=20 > prefer to wait for RS establishment. The current requirement wording=20 > indicates that CS dialog establishment MUST be delayed for RS=20 > establishment. [JRE] No, I believe it was not intended to force the CS to be delayed. A me= chanism that would meet this requirement without delaying CS establishment = would be to keep an RS permanently established, even when there is no CS, s= o that it can immediately be used when a new CS starts. This was the persistent recording use case (4), which I believe some people= felt was needed for some environments, and hence the desire to capture req= uirements that such environments have. Clearly we have failed to capture th= at requirements adequately - we need the right words. John (as individual) [DS] I agree with John's new wording, and that for this document we should simplify and state: o REQ-005 "The mechanism MUST support the ability to record a CS without loss of RS media while preparation for recording tak= es place." Although in a future version we might want to consider this area further. = =20 [DS] > > >=20 > > > 2. Recommend to change this: > > > o REQ-018 The mechanism MUST provide a means of > indicating to the > > > participants involved in a CS that their session is > > being recorded. > > >=20 > > > Examples include: inject tones into the CS from the SRC, play a > > > message at the beginning of a session, a visual indicator on a > > > display, etc. > > >=20 > > > To this: > > > o REQ-018 The mechanism MUST provide a means of > indicating to the > > > participants involved in a CS that their session is > > currently being > > > recorded. > > >=20 > > > Examples include: inject tones into the CS from the > SRC, a visual >=20 > > > indicator on a display > > >=20 > > > Added word "currently" because this is about providing an ongoing=20 > > > indicator during the call. Removed the "play a message...." part=20 > > > because playing a message at the beginning of a session is not a=20 > > > method that would require a siprec protocol solution, > it's n/a, it's >=20 > > > not about " an ongoing indicator." > [JRE] The word "currently" was there, in my opinion, because playing a=20 > message to indicate that recording might take place at some stage=20 > during the CS is what frequently happens and is sufficient for=20 > regulatory purposes in some jurisdictions. I agree it would not=20 > require a SIPREC protocol solution. Let's see what others say. > I agree with John that playing a message meet some of the=20 > Jurisdictions requirement. I like to hear from Dave whether any=20 > jurisdiction mandates for "injection tone" or "visual display". > >=20 [DS] I believe that informing ahead of time (that is, to indicate that rec= ording might take place at some stage during the CS) has nothing to do with= SIPREC. If that is a suitable solution for this req't then I believe we s= hould drop the req't entirely. =20 However, I see two reasons for functionality indicating that recording is "= currently" going on. And although I do not know of any regulations requiri= ng this functionality, I believe it is important. The reasons are: In order to inform (1) agents, and/or (2) customers that a call is "c= urrently" being recorded. =20 For many Customers, I believe that playing a message up-front via an IVR (f= or example) to "inform" them that "a call may be recorded..." may not be en= ough and that it would be desirable to also provide an ongoing indicator if recording is actually occurring "currently." Also, there are many examples where companies/environments want to be able to inform th= eir Agents when a call is "currently being recorded". [DS] =20 > Thanks > Partha >=20 > John (as individual) >=20 > > >=20 > > >=20 > > > 3. Recommend to change this: > > > o REQ-013 The mechanism MUST provide the SRS with the means to > > > correlate RS media with CS participant media described > > in metadata. > > >=20 > > > To this: > > > o REQ-013 The mechanism MUST provide the SRS with the means to > > > correlate RS media with CS participant media. > > >=20 > > > This is recommended because I don't see the need for the > part that > > > read "described in metadata" and because it is not clear what it=20 > > > meant. > > >=20 =20 [DS] I recommend to drop the wording "described in metadata" in REQ-013. [DS] > > >=20 > > > 4. Recommend to delete this Requirement: > > > o REQ-021 The mechanism MUST support means to relate Recording > > > Session(s) with Communication Session(s). > > >=20 > > > It is not needed since we have REQ-012 and REQ-013. =20 > > > [DS] I recommend to delete REQ-021. [DS] > > >=20 > > >=20 > > > Regards, > > > Dave > > >=20 > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > > Sent: Wednesday, January 12, 2011 4:12 AM > > > To: siprec@ietf.org > > > Subject: [siprec] Agenda requests plus reminder > > >=20 > > > Please let me have your agenda requests for the dual interim on=20 > > > 25th/26th. > > >=20 > > > Also, a reminder that WGLC on siprec-req is into its second > > week and I > > > have not seen any responses yet. Even if you are happy with it as=20 > > > is, a note to the list would be helpful. > > >=20 > > > John > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > >=20 > > > =09 > > > -------------------------------------------------------------- > > > ---------- > > > ------------------------------------------- > > > CONFIDENTIALITY NOTICE: This e-mail and any files attached > > may contain > > > confidential and proprietary information of Alcatel-Lucent > > and/or its > > > affiliated entities. Access by the intended recipient only is=20 > > > authorized. Any liability arising from any party acting, or > > refraining > > > from acting, on any information contained in this e-mail > is hereby > > > excluded. If you are not the intended recipient, please > notify the > > > sender immediately, destroy the original transmission and its=20 > > > attachments and do not disclose the contents to any other person,=20 > > > use it for any purpose, or store or copy the information in any=20 > > > medium. > > > Copyright in this e-mail and any attachments belongs to > > Alcatel-Lucent > > > and/or its affiliated entities. > > > =09 > > >=20 > > > =09 > > > -------------------------------------------------------------- > > > ----------------------------------------------------- > > > CONFIDENTIALITY NOTICE: This e-mail and any files attached may=20 > > > contain confidential and proprietary information of > Alcatel-Lucent > > > and/or its affiliated entities. Access by the intended recipient=20 > > > only is authorized. Any liability arising from any party > acting, or > > > refraining from acting, on any information contained in > this e-mail > > > is hereby excluded. If you are not the intended recipient, please=20 > > > notify the sender immediately, destroy the original > transmission and >=20 > > > its attachments and do not disclose the contents to any other=20 > > > person, use it for any purpose, or store or copy the > information in > > > any medium. Copyright in this e-mail and any attachments > belongs to > > > Alcatel-Lucent and/or its affiliated > > entities. > > > =09 > > >=20 > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >=20 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec =09 ---------------------------------------------------------------------------= ---------------------------------------- CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential and proprietary information of Alcatel-Lucent and/or its affiliate= d entities. Access by the intended recipient only is authorized. Any liabil= ity arising from any party acting, or refraining from acting, on any inform= ation contained in this e-mail is hereby excluded. If you are not the inten= ded recipient, please notify the sender immediately, destroy the original t= ransmission and its attachments and do not disclose the contents to any oth= er person, use it for any purpose, or store or copy the information in any = medium. Copyright in this e-mail and any attachments belongs to Alcatel-Luc= ent and/or its affiliated entities. =09 From Leon.Portman@nice.com Mon Jan 24 02:24:27 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6F503A682E for ; Mon, 24 Jan 2011 02:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.567 X-Spam-Level: X-Spam-Status: No, score=-0.567 tagged_above=-999 required=5 tests=[AWL=-1.867, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lQ8bQWaOnFW for ; Mon, 24 Jan 2011 02:24:26 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id 800EA3A69A0 for ; Mon, 24 Jan 2011 02:24:26 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Mon, 24 Jan 2011 12:27:14 +0200 From: Leon Portman To: "Hutton, Andrew" , "siprec@ietf.org" Date: Mon, 24 Jan 2011 12:27:13 +0200 Thread-Topic: WGLC comments on siprec-req-06 - AndyH Thread-Index: Acu2a/zhy6Eu2cCcTnKTjGmC9q4ZGwAb5lQgAHJVrpAAvD/TIA== Message-ID: <07465C1D981ABC41A344374066AE1A2C389F5D1034@TLVMBX01.nice.com> References: <101C6067BEC68246B0C3F6843BCCC1E30ABA829449@MCHP058A.global-ad.net> <07465C1D981ABC41A344374066AE1A2C389F44871A@TLVMBX01.nice.com> <101C6067BEC68246B0C3F6843BCCC1E30ABAA9C16B@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E30ABAA9C16B@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] WGLC comments on siprec-req-06 - AndyH X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 10:24:27 -0000 I am ok with that Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Hutton, Andrew Sent: Thursday, January 20, 2011 3:35 PM To: Leon Portman; siprec@ietf.org Subject: Re: [siprec] WGLC comments on siprec-req-06 - AndyH See my responses to Leon's comments below included suggested text for an ne= w multiple media stream requirement. Regards Andy > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: 18 January 2011 06:53 > To: Hutton, Andrew; siprec@ietf.org > Subject: RE: WGLC comments on siprec-req-06 - AndyH >=20 > Andy, Hi >=20 > Thank you for the comments > Please see below >=20 > Leob >=20 > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Hutton, Andrew > Sent: Monday, January 17, 2011 7:29 PM > To: siprec@ietf.org > Subject: [siprec] WGLC comments on siprec-req-06 - AndyH >=20 > A few WGLC comments on the draft. >=20 > 1. Abstract: "Recording is typically done by". Maybe could replace=20 > "done" with "achieved" or "perfomed". >=20 > [leon] don't have any strong opinion about it >=20 > 2. Definitions, 2nd Para":=20 > "The SRC itself or another entity working on its behalf (such as a SIP=20 > Application Server) may act as the source of the recording metadata." > I believe it is the SRC which is always the source of the metadata.=20 > However of course the SRC could be decomposed in various ways but it=20 > is still a component of the SRC which is the source of metadata. If an=20 > SRC receives information from somewhere else which it uses as metadata=20 > then that is also out of scope. >=20 > [leon] I don't think that we should limit scope in such way.=20 > Why do we care if SRC received metadata from some other entity, like=20 > CTI server for backward compatibility case? [Andy H] - We don't care how the SRC receives the metadata however for the= purposes of SIPREC we assume that the SRC is the only entity that sends me= tadata to the SRS. The current text could be interpreted as indicating that= something other than the SRC is able to send metadata to the SRS which is = I believe incorrect. > =20 > 3. Section 4, Use Case 1:=20 > "Use Case 1: Full-time Recording: One (or more, in the case of > redundant recording) Recording Session for each Communication > Session." > There is no other reference to "redundant recording" in the document I=20 > think we should therefore remove this statement. I think we agreed=20 > that this was just an implementation option and did not need to be a=20 > requirement [leon] May be "duplicate" will be a better term? It is=20 > just an example, and not actual requirement >=20 [Andy H] My preference would be to remove statements all statements on "Red= undant" or "Duplicate" recording. > 4. Section 5, Req 10. > "REQ-010 The mechanism MUST support the ability to deliver to the > SRS multiple media streams for a given CS." > Does this refer to the case of multiple media types (E.g.=20 > Voice, Video etc.) or does it mean multiple media streams of the same=20 > type (i.e. one per participant)? I think we might need to explicitly=20 > state a requirement for unmixed audio streams from different parties. > [leon] Yes, it means actually both. It is obvious for different types=20 > and not so obvious for unmixed streams >=20 [Andy H] - Agreed so we need a REQ-XX which might state "The mechanism MUST= support the ability to deliver to the SRS multiple media streams of the sa= me media type (e.g. audio, video). For example in the case of delivering un= mixed audio for each participant in the CS".=20 > Regards > Andy >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >=20 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Mon Jan 24 02:51:40 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50E6A3A67FD for ; Mon, 24 Jan 2011 02:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5dPNg1BXkwW for ; Mon, 24 Jan 2011 02:51:38 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 917093A63C9 for ; Mon, 24 Jan 2011 02:51:38 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3116822 for siprec@ietf.org; Mon, 24 Jan 2011 11:54:31 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id E084523F0278 for ; Mon, 24 Jan 2011 11:54:31 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 24 Jan 2011 11:54:31 +0100 From: "Elwell, John" To: "siprec@ietf.org" Date: Mon, 24 Jan 2011 11:54:30 +0100 Thread-Topic: SIPREC interim virtual meetings on Tuesday/Wednesday this week Thread-Index: Acu7tROrarzbjz4nTEWdm+CLJrh8CA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] SIPREC interim virtual meetings on Tuesday/Wednesday this week X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 10:51:40 -0000 Reminder - first session starts 15.00 GMT tomorrow (Tuesday), second sessio= n starts 14.00 GMT Wednesday. Webex information and materials are available courtesy of Ken at: http://kenrehor.com/ietf/siprec/IETF79.2/ John= From partr@cisco.com Mon Jan 24 04:26:50 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 361E63A6AC3 for ; Mon, 24 Jan 2011 04:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.535 X-Spam-Level: X-Spam-Status: No, score=-9.535 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, J_CHICKENPOX_28=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQ+oZ4gjuJ-h for ; Mon, 24 Jan 2011 04:26:48 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9C06A3A67FD for ; Mon, 24 Jan 2011 04:26:48 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAJf/PE1AaMHG/2dsb2JhbACCQKIlc6AummCFUASEbold Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-6.cisco.com with ESMTP; 24 Jan 2011 12:29:42 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0OCSuVN018476; Mon, 24 Jan 2011 12:29:40 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Jan 2011 17:59:23 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBBBC2.54AB2651" Date: Mon, 24 Jan 2011 17:59:20 +0530 Message-ID: In-Reply-To: <07465C1D981ABC41A344374066AE1A2C389F5D1032@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ram-siprec-metadata-format-00 for Review Thread-Index: Acu5mQo4RC5BhuXCQFOzg3WgV44EjAAABm26AH5aJ7AACZpxsA== References: <20110121182547.848C43A6A80@core3.amsl.com> <07465C1D981ABC41A344374066AE1A2C389F5D1032@TLVMBX01.nice.com> From: "Parthasarathi R (partr)" To: "Leon Portman" , X-OriginalArrivalTime: 24 Jan 2011 12:29:23.0500 (UTC) FILETIME=[550A9EC0:01CBBBC2] Subject: Re: [siprec] draft-ram-siprec-metadata-format-00 for Review X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 12:26:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBBBC2.54AB2651 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Leon, =20 Thanks for your comments. Please read inline. =20 Thanks Partha ________________________________ From: Leon Portman [mailto:Leon.Portman@nice.com]=20 Sent: Monday, January 24, 2011 3:57 PM To: Parthasarathi R (partr); siprec@ietf.org Subject: RE: draft-ram-siprec-metadata-format-00 for Review Partha, Hi =20 Thank you very much for posting. Following my comments: =20 1. Do we want also considering supporting light-weight formats like JSON or compressed XML?=20 XML is chosen for exchanging metadata as lot of other SIP standards like XCON, PIDF uses XML for data exchange and it is widely deployed in lot of SIP devices. XML has the advantage of better interop as it is open standard (W3C) and already adopted. =20 I'm not sure whether we prefer compressed XML as XML data is not going to be too huge for SIPREC metadata and also XML provides more readability. But in case you have some strong reason for exploring compressed XML, Please let us know. =20 I'm hearing about JSON for the first time :-). At the first glance of web search on"JSON vs XML", I see the argument in the both directions. I'll explore further in detail to understand pros & cons between "JSON vs XML". I'm interested in hearing from others about their opinion on JSON =20 2. 4.2.3 SRS does not have any knowledge to generate group id. And it is also supposed to be populated by the sender (SRC)=20 I agree with you that SRC should have knowledge about CS grouping. I have put it as an open issue in sec 4.2.3 as SRC may not be able to create unique group-id to SRS in case multiple SRC communicates with SRS and all SRC may create same-id at the particular instances for different group. Here, SRS may adds the portion of group id to create uniqueness. In case you foresee that single SRC generates unique-id in multiple SRC to single SRS topology, SRC will be able to generate the key. =20 3. 4.2.11 It should be UTC time stamp, preferably with 10ms resolution=20 xs:dateTime is used to represent timestamp which permits UTC timestamp. 4. I am still missing how we will report updates: like adding participants or removing media streams. We should support sending only updates tupples and also indication if they were removed=20 =20 The current idea of XML schema is to pass the complete metadata details of CS in each RS transaction. SRS will be able deduced the change by comparing previous instance metadata with current one. The complete XML schema is helpful in case of transfer sort of scenario wherein most of the details like CS, participant,stream changes but it is sub-optimal incase of call Hold/resume. =20 We (authors) discussed for passing the partial data for addition, updating, deletion. Partial data passing for addition or updating is straightforward whereas deletion using partial data involves lot of complexity in the mechanism. So, we thought of getting the feedback before including the format in draft and it is mentioned this idea in Sec 4.2.2 as =20 o Open Issue: whether Partial update of Metadata XML document is required ? I'm taking your comment for adding partial update in Metadata XML document.=20 =20 For passing partial metadata in XML document, each element (stream, participant, session) which has to be passed indepently has to be represented as a separate namespace extension. =20 Regards =20 Leon =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) Sent: Friday, January 21, 2011 8:42 PM To: siprec@ietf.org Subject: [siprec] draft-ram-siprec-metadata-format-00 for Review =20 Hi all, =20 Paul, Ram and myself have posted the initial Metadata format -00 draft based on Metadata model draft(draft-ram-siprec-metadata). Metadata format introduces new SIPREC metadata specific XML document and links to SDP for media parameters. The draft provides realization of Metadata model. =20 This draft is in initial stage with lot of open item. The basic idea of posting this draft is to get the high level consensus, start the discussion on interim meeting before deep dive into individual items. =20 Thanks Partha =20 ________________________________ From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Fri 1/21/2011 11:55 PM To: Parthasarathi R (partr) Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) Subject: New Version Notification for draft-ram-siprec-metadata-format-00=20 =20 A new version of I-D, draft-ram-siprec-metadata-format-00.txt has been successfully submitted by Parthasarathi R and posted to the IETF repository. Filename: draft-ram-siprec-metadata-format Revision: 00 Title: Session Initiation Protocol (SIP) Recording Metadata Format Creation_date: 2011-01-21 WG ID: Independent Submission Number_of_pages: 14 Abstract: 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. The requirements for which are described in [I-D.ietf-siprec-req], the architecture for which is described in [I-D.ietf-siprec-architecture], and the metadata model viewed by Session Recording Server is described in [I-D.ram-siprec-metadata]. This document focuses on the Recording metadata format which describes the communication session. =20 The IETF Secretariat. ------_=_NextPart_001_01CBBBC2.54AB2651 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New = Version Notification for draft-ram-siprec-metadata-format-00
Hi Leon,
 
Thanks for your comments. Please read=20 inline.
 
Thanks
Partha

From: Leon Portman=20 [mailto:Leon.Portman@nice.com]
Sent: Monday, January 24, 2011 = 3:57=20 PM
To: Parthasarathi R (partr); = siprec@ietf.org
Subject: RE:=20 draft-ram-siprec-metadata-format-00 for Review

Partha,=20 Hi

 

Thank=20 you very much for posting. Following my comments:

 

1.      =20 Do=20 we want also considering supporting light-weight formats like JSON or = compressed=20 XML? 

<Partha>=20 XML is chosen for exchanging metadata as lot of other SIP = standards=20 like XCON, PIDF uses XML for data exchange and it is widely=20 deployed in lot of SIP devices. XML has the advantage of = better=20 interop as it is open standard (W3C) and already=20 adopted.

     

      I'm not sure = whether we=20 prefer compressed XML as XML data is not going to be too huge for = SIPREC=20 metadata and also XML provides more readability. But in case you have = some=20 strong reason for exploring compressed XML, Please let us=20 know.

 

      I'm hearing = about JSON for=20 the first time :-). At the first glance of web search on"JSON = vs XML",=20 I see the argument in the both directions. I'll explore further in = detail=20 to understand pros & cons between "JSON vs=20 XML".   I'm = interested in=20 hearing from others about their opinion on JSON=20 </Partha>

 

2.      =20 4.2.3=20 SRS does not have any knowledge to generate group id. And it is also = supposed to=20 be populated by the sender (SRC) 

<Partha>  I agree with you that = SRC should=20 have knowledge about CS grouping. I have put it as an open issue in = sec=20 4.2.3 as SRC may not be able to create unique group-id to SRS in = case=20 multiple SRC communicates with SRS and all SRC may create same-id = at the=20 particular instances for different group. Here, SRS may adds the portion = of=20 group id to create uniqueness. In case you foresee that single SRC generates unique-id in = multiple=20 SRC to single SRS topology, SRC will be able to generate the key.=20 </Partha>

 

3.      =20 4.2.11=20 It should be UTC time stamp, preferably with 10ms resolution 

<Partha>=20  xs:dateTime is = used to=20 represent timestamp which permits UTC timestamp.=20 </Partha>

4.      =20 I=20 am still missing how we will report updates: like adding participants or = removing media streams. We should support sending only updates tupples = and also=20 indication if they were removed 

 

<partha>=20 The current idea of XML schema is to pass the = complete metadata=20 details of CS in each RS transaction. SRS will be able deduced the = change by=20 comparing previous instance metadata with current = one.  The=20 complete XML schema is helpful in case of transfer sort of scenario = wherein most=20 of the details like CS, participant,stream changes but it is sub-optimal = incase=20 of call Hold/resume.

 

      We (authors) discussed for = passing the=20 partial data for addition, updating, deletion. Partial data passing for = addition=20 or updating is straightforward whereas deletion using partial data = involves=20 lot of complexity in the mechanism.  So, we thought = of getting=20 the feedback before including the format in draft and it is = mentioned=20 this idea in Sec 4.2.2 as   

       &nbs= p;   =20 o  Open Issue: whether Partial update of = Metadata XML=20 document is  required ?

      I'm taking your comment for adding = partial=20 update in Metadata XML document.

 

     For passing partial metadata in = XML=20 document, each element (stream, participant, session) which has to be = passed=20 indepently has to be represented as a separate namespace=20 extension.

</partha>

 

Regards

 

Leon

 

From:=20 siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Parthasarathi R (partr)
Sent: Friday, January 21, 2011 = 8:42=20 PM
To: siprec@ietf.org
Subject: [siprec]=20 draft-ram-siprec-metadata-format-00 for = Review

 

Hi=20 all,

 

Paul, Ram = and=20 myself have posted the initial Metadata format -00 draft based on = Metadata=20 model draft(draft-ram-siprec-metadata). Metadata format introduces new = SIPREC=20 metadata specific XML document and links to SDP for media parameters. = The draft=20 provides realization of Metadata model.

 

This draft = is in=20 initial stage with lot of open item. The basic idea of posting this = draft is to=20 get the high level consensus, start the discussion on interim=20 meeting before deep dive into individual = items.

 

Thanks

Partha

 

From: IETF I-D = Submission=20 Tool [mailto:idsubmission@ietf.org]
Sent: Fri 1/21/2011 11:55=20 PM
To: Parthasarathi R (partr)
Cc: Ram Mohan R = (rmohanr);=20 Paul Kyzivat (pkyzivat)
Subject: New Version Notification for=20 draft-ram-siprec-metadata-format-00

 

A new = version of=20 I-D, draft-ram-siprec-metadata-format-00.txt has been successfully = submitted by=20 Parthasarathi R and posted to the IETF=20 repository.

Filename:       =20 draft-ram-siprec-metadata-format
Revision:    &nbs= p;  =20 00
Title:           = Session=20 Initiation Protocol (SIP) Recording Metadata=20 Format
Creation_date:   2011-01-21
WG ID: =20          Independent=20 Submission
Number_of_pages: 14

Abstract:
Session recording = is a=20 critical requirement in many communications
environments such as call = centers=20 and financial trading.  In some of
these environments, all calls = must be=20 recorded for regulatory,
compliance, and consumer protection = reasons. =20 Recording of a session
is typically performed by sending a copy of a = media=20 stream to a
recording device.  The requirements for which are = described=20 in
[I-D.ietf-siprec-req], the architecture for which is described=20 in
[I-D.ietf-siprec-architecture], and the metadata model viewed=20 by
Session Recording Server is described in=20 [I-D.ram-siprec-metadata].
This document focuses on the Recording = metadata=20 format which
describes the communication=20 session.
          &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =           


T= he=20 IETF = Secretariat.

------_=_NextPart_001_01CBBBC2.54AB2651-- From acooper@cdt.org Mon Jan 24 05:03:27 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 512CD28C0CF for ; Mon, 24 Jan 2011 05:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.153 X-Spam-Level: X-Spam-Status: No, score=-102.153 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1QYvwnjWfDY for ; Mon, 24 Jan 2011 05:03:26 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id F166928B23E for ; Mon, 24 Jan 2011 05:03:25 -0800 (PST) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Mon, 24 Jan 2011 08:06:05 -0500 Message-Id: From: Alissa Cooper To: Deepanshu Gautam In-Reply-To: <008b01cbabb5$dfde01d0$9f9a0570$@com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 24 Jan 2011 13:06:01 +0000 References: <7744FE52C78D944587F03773EB45146109139DEE@xmb-sjc-22e.amer.cisco.com> <07465C1D981ABC41A344374066AE1A2C389EB6D950@TLVMBX01.nice.com> <008b01cbabb5$dfde01d0$9f9a0570$@com> X-Mailer: Apple Mail (2.936) Cc: siprec@ietf.org, 'Leon Portman' Subject: Re: [siprec] draft-ietf-siprec-req-06 posted X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 13:03:27 -0000 Hi all, On Jan 4, 2011, at 2:19 AM, Deepanshu Gautam wrote: > I think the original intention for these requirements was indeed the =20= > stop of recording and/or discard any metadata already submitted. The =20= > word =91cancel=92 *is* implying a stop-of-recording. You don=92t = cancel =20 > existing recording, you delete existing/discard recording. I think =20 > the wording is fine. If "cancel" is really being used here to mean "stop," why not just use =20= "stop" (or "terminate," as is used in section 6) in req-15 and req-16? =20= It might avoid confusion over whether the recording is meant to =20 continue after discarding one portion. Alissa > > We can add something related with =93- a policy at the SRS whether to =20= > honor such a request.=94 If we really need that at requirement level > < Regards > > Deepanshu Gautam > T: +86 25 5260008 M: +86 135 85147627 > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On =20 > Behalf Of Parthasarathi R (partr) > Sent: Tues day, Jan To: Leon Portman; Ken Rehor (krehor); = siprec@ietf.org > Subject: Re: [siprec] draft-ietf-siprec-req-06 posted > > Leon, > > Please read inline. > > Th anks > Partha > > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: Mon 1/3/2011 5:34 PM > To: Parthasarathi R (partr); Ken Rehor (krehor); siprec@ietf.org > Subject: RE: [siprec] draft-ietf-siprec-req-06 posted > > Partha, Hi > > I am not sure about removing. It is requirement level document and =20 > how to implement it either via policy > In case of policy, there is no need of configuration Partha> > and metadata indication it is more protocol level decision. > As per the last meeting, the information is not passed in =20 > metadata model. If required, we need to revisit th e metada Partha> > =46rom my point of view it is also two separate flows: indicating =20 > retention parameters or immediate stop of the recording. > The requirement wordings does not look like stop of the =20 > recording. The intention is to cancel and discard the existing =20 > recording of specific RS > For example, SRC for some reason wants to cancel recording, the best =20= > way will be to send BYE with specific error code and not metadata =20 > update event. > I agree that different way to achieve it in SIPREC =20 > solution. Metadata model composes of all recording related& nbsp;sig =20= > between between SRS and SRC. As part of SIPREC solution, We may =20 > decide to use error code in BYE to cancel and discard recording but =20= > we have to represent it in the metadata model. Please let me know =20 > your opinion here. > > Regards > > Leon > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On =20 > Behalf Of Parthasarathi R (partr) > Sent: Monday, January To: Ken Rehor (krehor); siprec@ietf.org > Subject: Re: [siprec] draft-ietf-siprec-req-06 posted > > Ken and all, > > During the last interim meeting, it was decided to put the "forced =20 > deletion" attribute in the appdata of Metadata model instead of =20 > including in the model. Cancel and discard recording from SRC is =20 > considered as policy mechanism passing to SRS. If so, the following =20= > requirements has to be removed from SIPREC requirement: > > o REQ-015: The mechanism MUST support a means to bsp; the =20 > recording and associated metadata for a CS. > > o REQ-016: The mechanism MUST support a means to cancel and discard > the recording but not the associated metadata for a CS. > Please let me know your opinion on the same. > > Thanks > Partha > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On =20 > Behalf Of Ken Rehor (krehor) > Sent: Saturday, January 01, 2011 11:39 AM > To: siprec@ietf.org > Subject: [siprec] draft-ietf-siprec-req-06 posted > > - ietf-siprec-req-06 posted = http://www.ietf.org/internet-drafts/draft-ietf-siprec-req-06.txt > - tracker item #61 closed > - Draft and change log attached > > Happy New Year! > > Ken > > > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From acooper@cdt.org Mon Jan 24 05:08:04 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34B673A6845 for ; Mon, 24 Jan 2011 05:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.446 X-Spam-Level: X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbXG36hZxv99 for ; Mon, 24 Jan 2011 05:08:03 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 56E043A68C8 for ; Mon, 24 Jan 2011 05:08:03 -0800 (PST) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Mon, 24 Jan 2011 08:10:55 -0500 Message-Id: <251DA7F9-19A9-488F-B39A-69376D800BBD@cdt.org> From: Alissa Cooper To: John Elwell , siprec@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 24 Jan 2011 13:10:54 +0000 References: X-Mailer: Apple Mail (2.936) Subject: Re: [siprec] Extension to WGLC for siprec-req X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 13:08:04 -0000 Looks ready to go (other than the slight clarification I just inquired about re req-15 and req-16). A couple of nits in section 6: s/if caller does not trust/if the caller does not trust/ s/for what purpose can the recording be/for what purpose the recording can be/ Alissa On Jan 18, 2011, at 3:36 PM, Elwell, John wrote: > There was a disappointingly poor response to WGLC, which ended > yesterday. Therefore the chairs have decided to extend WGLC until > next Monday, 2011-01-24 (i.e., to finish the day before the interim > virtual meeting). Please submit your comments and/or indicate > whether you consider the document ready to go by that date. > > John > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From Henry.Lum@alcatel-lucent.com Mon Jan 24 07:29:04 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2E9C3A6944 for ; Mon, 24 Jan 2011 07:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.052 X-Spam-Level: X-Spam-Status: No, score=-6.052 tagged_above=-999 required=5 tests=[AWL=0.547, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3LqT1xe127K for ; Mon, 24 Jan 2011 07:29:03 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 92CDA3A68D5 for ; Mon, 24 Jan 2011 07:29:03 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p0OFVu2H011236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 Jan 2011 09:31:56 -0600 (CST) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [172.22.70.114]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0OFVsnh005433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Jan 2011 09:31:55 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.wc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id p0OFVqHP003748; Mon, 24 Jan 2011 07:31:53 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Jan 2011 07:31:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Jan 2011 07:31:52 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF7406989978@NAHALD.us.int.genesyslab.com> In-Reply-To: <4D3D8671.4000106@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Use of INFO for siprec metadata Thread-Index: Acu7z1dUtOin39xkShy0ONjnPmJqrgAC5Kcg References: <7744FE52C78D944587F03773EB45146109406415@xmb-sjc-22e.amer.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05024EF5@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05024EFA@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05024F0C@XMB-BGL-417.cisco.com> <059AF07365DC474393A19A3AF187DF7401A5BD7A@NAHALD.us.int.genesyslab.com> <4D3D8671.4000106@cisco.com> From: "Henry Lum" To: "Paul Kyzivat" , "Parthasarathi R (partr)" , X-OriginalArrivalTime: 24 Jan 2011 15:31:53.0488 (UTC) FILETIME=[D3BE3100:01CBBBDB] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: Leon Portman Subject: Re: [siprec] Use of INFO for siprec metadata X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 15:29:04 -0000 Hi Paul, If we have an RS that only wants to send metadata without recorded media, INFO can also be useful for this case without resorting to UPDATE.=20 With UPDATE or content in INVITE/PRACK, what can we do if we want a mechanism to report errors in metadata from the SRS to the SRC?=20 Let's bring this into the mailing list. Henry > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, January 24, 2011 9:02 AM > To: Parthasarathi R (partr) > Cc: Henry Lum; Elwell, John; Ram Mohan R (rmohanr); Ken Rehor (krehor); > Leon Portman > Subject: Use of INFO for siprec metadata >=20 > I question the value of using INFO for metadata. My reasoning is as > follows: >=20 > - there is need to transmit metadata in conjunction with > media stream creation/change. >=20 > - the media stream creation/change happens as a result of o/a. >=20 > - the o/a happens in INVITE/UPDATE/PRACK and their responses. >=20 > - therefore there is a need to transmit metadata with those messages. >=20 > - in those cases where there is need to transmit metadata even > though there is no media stream change, it could be sent in an > UPDATE (since there will be mechanism to use UPDATE.) >=20 > The alternative would be to restrict metadata to INFO messages. But > then > the metadata about a media stream creation/change would have to follow > the message that did the media change, so there would be a delay in > understanding what it was about. And a need to cross reference between > the two messages. That seems at best inconvenient. >=20 > Thanks, > Paul >=20 =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From pkyzivat@cisco.com Mon Jan 24 07:43:04 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91A8C3A6AEA for ; Mon, 24 Jan 2011 07:43:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.487 X-Spam-Level: X-Spam-Status: No, score=-110.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nive4CATtcMg for ; Mon, 24 Jan 2011 07:43:03 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8EE683A6AE2 for ; Mon, 24 Jan 2011 07:43:03 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkGAEotPU1AZnwN/2dsb2JhbACWS44dc6BimxCFUASEcIYwgyU Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 24 Jan 2011 15:45:58 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0OFjw04001635 for ; Mon, 24 Jan 2011 15:45:58 GMT Message-ID: <4D3D9EB6.1060402@cisco.com> Date: Mon, 24 Jan 2011 10:45:58 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: siprec@ietf.org References: <7744FE52C78D944587F03773EB45146109406415@xmb-sjc-22e.amer.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05024EF5@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05024EFA@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05024F0C@XMB-BGL-417.cisco.com> <059AF07365DC474393A19A3AF187DF7401A5BD7A@NAHALD.us.int.genesyslab.com> <4D3D8671.4000106@cisco.com> <059AF07365DC474393A19A3AF187DF7406989978@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF7406989978@NAHALD.us.int.genesyslab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Use of INFO for siprec metadata X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 15:43:04 -0000 On 1/24/2011 10:31 AM, Henry Lum wrote: > Hi Paul, > > If we have an RS that only wants to send metadata without recorded > media, INFO can also be useful for this case without resorting to > UPDATE. > > With UPDATE or content in INVITE/PRACK, what can we do if we want a > mechanism to report errors in metadata from the SRS to the SRC? > > Let's bring this into the mailing list. Assuming we have a mechanism to use UPDATE to send metadata, then that will work even if the UPDATE does not include and o/a. Of course INFO would also work. It just seems an unnecessary complication to pull in the info package mechanism. (If we didn't ever need to send metadata with messages carrying o/a then I would *prefer* to use INFO.) Thanks, Paul > Henry > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Monday, January 24, 2011 9:02 AM >> To: Parthasarathi R (partr) >> Cc: Henry Lum; Elwell, John; Ram Mohan R (rmohanr); Ken Rehor > (krehor); >> Leon Portman >> Subject: Use of INFO for siprec metadata >> >> I question the value of using INFO for metadata. My reasoning is as >> follows: >> >> - there is need to transmit metadata in conjunction with >> media stream creation/change. >> >> - the media stream creation/change happens as a result of o/a. >> >> - the o/a happens in INVITE/UPDATE/PRACK and their responses. >> >> - therefore there is a need to transmit metadata with those messages. >> >> - in those cases where there is need to transmit metadata even >> though there is no media stream change, it could be sent in an >> UPDATE (since there will be mechanism to use UPDATE.) >> >> The alternative would be to restrict metadata to INFO messages. But >> then >> the metadata about a media stream creation/change would have to follow >> the message that did the media change, so there would be a delay in >> understanding what it was about. And a need to cross reference between >> the two messages. That seems at best inconvenient. >> >> Thanks, >> Paul >> > > > ------------------------------------------------------------------------------------------------------------------- > CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities. > > From Henry.Lum@alcatel-lucent.com Mon Jan 24 13:29:29 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48CA03A6928 for ; Mon, 24 Jan 2011 13:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.112 X-Spam-Level: X-Spam-Status: No, score=-6.112 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNoB2BR3m6hB for ; Mon, 24 Jan 2011 13:29:21 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id EDAC23A6922 for ; Mon, 24 Jan 2011 13:29:20 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p0OLWE9S018458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 Jan 2011 15:32:14 -0600 (CST) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [172.22.70.114]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0OLWDtI012288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Jan 2011 15:32:14 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.wc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id p0OLWDhQ011120; Mon, 24 Jan 2011 13:32:13 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Jan 2011 13:32:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBBC0E.299D550D" Date: Mon, 24 Jan 2011 13:32:11 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF7406989A96@NAHALD.us.int.genesyslab.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] draft-ram-siprec-metadata-format-00 for Review Thread-Index: Acu5mQo4RC5BhuXCQFOzg3WgV44EjAAABm26AJwiqMA= References: <20110121182547.848C43A6A80@core3.amsl.com> From: "Henry Lum" To: "Parthasarathi R (partr)" , X-OriginalArrivalTime: 24 Jan 2011 21:32:12.0634 (UTC) FILETIME=[29C213A0:01CBBC0E] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [siprec] draft-ram-siprec-metadata-format-00 for Review X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 21:29:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBBC0E.299D550D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Partha, =20 This is a good start, and the main concern I have is the declarative nature of this format. Since metadata is delivered as a stream of events, so whenever something changes in the CS (ie. added a participant, or participant muted audio), would the SRC report the change by providing the entire declaration as a snapshot again? The problem I see here is the SRS would end up with the responsibility to figure out the changes made since the last snapshot. It's kind of like doing a diff against the previous snapshot if the SRS needs to know what the metadata event is about. =20 I am wondering if we can using something like the XCON event package although it's expired, and this is based on RFC5261 which uses XPath to locate and make changes to the snapshot. =20 Regards, Henry =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) Sent: Friday, January 21, 2011 1:42 PM To: siprec@ietf.org Subject: [siprec] draft-ram-siprec-metadata-format-00 for Review =20 Hi all, =20 Paul, Ram and myself have posted the initial Metadata format -00 draft based on Metadata model draft(draft-ram-siprec-metadata). Metadata format introduces new SIPREC metadata specific XML document and links to SDP for media parameters. The draft provides realization of Metadata model. =20 This draft is in initial stage with lot of open item. The basic idea of posting this draft is to get the high level consensus, start the discussion on interim meeting before deep dive into individual items. =20 Thanks Partha =20 ________________________________ From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Fri 1/21/2011 11:55 PM To: Parthasarathi R (partr) Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) Subject: New Version Notification for draft-ram-siprec-metadata-format-00=20 =20 A new version of I-D, draft-ram-siprec-metadata-format-00.txt has been successfully submitted by Parthasarathi R and posted to the IETF repository. Filename: draft-ram-siprec-metadata-format Revision: 00 Title: Session Initiation Protocol (SIP) Recording Metadata Format Creation_date: 2011-01-21 WG ID: Independent Submission Number_of_pages: 14 Abstract: 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. The requirements for which are described in [I-D.ietf-siprec-req], the architecture for which is described in [I-D.ietf-siprec-architecture], and the metadata model viewed by Session Recording Server is described in [I-D.ram-siprec-metadata]. This document focuses on the Recording metadata format which describes the communication session. =20 The IETF Secretariat. =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 ------_=_NextPart_001_01CBBC0E.299D550D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New Version Notification for draft-ram-siprec-metadata-format-00</= title> <style> <!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p {mso-style-priority:99; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:12.0pt; font-family:"Times New Roman","serif";} span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:blue; font-weight:normal; font-style:normal; text-decoration:none none;} =2EMsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.Section1 {page:Section1;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri= ","sans-serif"; color:blue'>Hi Partha,<o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri= ","sans-serif"; color:blue'><o:p> </o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri= ","sans-serif"; color:blue'>This is a good start, and the main concern I have is the decl= arative nature of this format. Since metadata is delivered as a stream of events,= so whenever something changes in the CS (ie. added a participant, or partici= pant muted audio), would the SRC report the change by providing the entire declaration as a snapshot again? The problem I see here is the SRS would = end up with the responsibility to figure out the changes made since the last sna= pshot. It’s kind of like doing a diff against the previous snapshot if the= SRS needs to know what the metadata event is about.<o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri= ","sans-serif"; color:blue'><o:p> </o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri= ","sans-serif"; color:blue'>I am wondering if we can using something like the XCON event package although it’s expired, and this is based on RFC5261 which u= ses XPath to locate and make changes to the snapshot.<o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri= ","sans-serif"; color:blue'><o:p> </o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri= ","sans-serif"; color:blue'>Regards,<o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri= ","sans-serif"; color:blue'>Henry<o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri= ","sans-serif"; color:blue'><o:p> </o:p></span></p> <div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0i= n 4.0pt'> <div> <div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0i= n 0in 0in'> <p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Taho= ma","sans-serif"'>From:</span></b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] <b>On Behalf Of = </b>Parthasarathi R (partr)<br> <b>Sent:</b> Friday, January 21, 2011 1:42 PM<br> <b>To:</b> siprec@ietf.org<br> <b>Subject:</b> [siprec] draft-ram-siprec-metadata-format-00 for Review<o= :p></o:p></span></p> </div> </div> <p class=3DMsoNormal><o:p> </o:p></p> <div id=3DidOWAReplyText35468> <div> <p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial",= "sans-serif"; color:black'>Hi all,</span><o:p></o:p></p> </div> <div> <p class=3DMsoNormal> <o:p></o:p></p> </div> <div> <p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial",= "sans-serif"'>Paul, Ram and myself have posted the initial Metadata format -00 draft bas= ed on Metadata model draft(draft-ram-siprec-metadata). Metadata format introduc= es new SIPREC metadata specific XML document and links to SDP for media paramete= rs. The draft provides realization of Metadata model.</span><o:p></o:p></p> </div> <div> <p class=3DMsoNormal> <o:p></o:p></p> </div> <div> <p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial",= "sans-serif"'>This draft is in initial stage with lot of open item. The basic idea of postin= g this draft is to get the high level consensus, start the discussion on interim= meeting before deep dive into individual items.</span><o:p></o:p></p= > </div> <div> <p class=3DMsoNormal> <o:p></o:p></p> </div> <div> <p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial",= "sans-serif"'>Thanks</span><o:p></o:p></p> </div> <div> <p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial",= "sans-serif"'>Partha</span><o:p></o:p></p> </div> </div> <div> <p class=3DMsoNormal><o:p> </o:p></p> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'> <hr size=3D2 width=3D"100%" align=3Dcenter> </div> <p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><span style=3D'fon= t-size:10.0pt; font-family:"Tahoma","sans-serif"'>From:</span></b><span style=3D'font-si= ze:10.0pt; font-family:"Tahoma","sans-serif"'> IETF I-D Submission Tool [mailto:idsubmission@ietf.org]<br> <b>Sent:</b> Fri 1/21/2011 11:55 PM<br> <b>To:</b> Parthasarathi R (partr)<br> <b>Cc:</b> Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)<br> <b>Subject:</b> New Version Notification for draft-ram-siprec-metadata-format-00 </span><o:p></o:p></p> </div> <div> <p class=3DMsoNormal><o:p> </o:p></p> <p style=3D'margin-bottom:12.0pt'><span style=3D'font-size:10.0pt'>A new = version of I-D, draft-ram-siprec-metadata-format-00.txt has been successfully submit= ted by Parthasarathi R and posted to the IETF repository.<br> <br> Filename:        draft-ram-siprec-meta= data-format<br> Revision:        00<br> Title:           Session Initiation Protocol (SIP) Recording Metadata Format<br> Creation_date:   2011-01-21<br> WG ID:           Independent= Submission<br> Number_of_pages: 14<br> <br> Abstract:<br> Session recording is a critical requirement in many communications<br> environments such as call centers and financial trading.  In some of= <br> these environments, all calls must be recorded for regulatory,<br> compliance, and consumer protection reasons.  Recording of a session= <br> is typically performed by sending a copy of a media stream to a<br> recording device.  The requirements for which are described in<br> [I-D.ietf-siprec-req], the architecture for which is described in<br> [I-D.ietf-siprec-architecture], and the metadata model viewed by<br> Session Recording Server is described in [I-D.ram-siprec-metadata].<br> This document focuses on the Recording metadata format which<br> describes the communication session.<br>             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =         <br> <br> <br> The IETF Secretariat.<br> <br> </span><o:p></o:p></p> </div> </div> </div> <DIV> </DIV><br/><div style=3D"border:none;border-top:solid #B5C4DF = 1.0pt;padding:3.0pt 0in 0in 0in"/><br/>CONFIDENTIALITY NOTICE: This e-mai= l and any files attached may contain confidential and proprietary informa= tion of Alcatel-Lucent and/or its affiliated entities. Access by the inte= nded recipient only is authorized. Any liability arising from any party a= cting, or refraining from acting, on any information contained in this e-= mail is hereby excluded. If you are not the intended recipient, please no= tify the sender immediately, destroy the original transmission and its at= tachments and do not disclose the contents to any other person, use it fo= r any purpose, or store or copy the information in any medium. Copyright = in this e-mail and any attachments belongs to Alcatel-Lucent and/or its a= ffiliated entities.</body> </html> ------_=_NextPart_001_01CBBC0E.299D550D-- From Leon.Portman@nice.com Mon Jan 24 17:30:57 2011 Return-Path: <Leon.Portman@nice.com> X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD9863A6B46 for <siprec@core3.amsl.com>; Mon, 24 Jan 2011 17:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FF+zJIEdVfAH for <siprec@core3.amsl.com>; Mon, 24 Jan 2011 17:30:56 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id 9365F3A6847 for <siprec@ietf.org>; Mon, 24 Jan 2011 17:30:55 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Tue, 25 Jan 2011 03:33:45 +0200 From: Leon Portman <Leon.Portman@nice.com> To: "siprec@ietf.org" <siprec@ietf.org> Date: Tue, 25 Jan 2011 03:33:37 +0200 Thread-Topic: [siprec] Summary of open items fron WGLC Thread-Index: Acu8LgmM3YpmHvKvQpybOZYKNtoI1w== Message-ID: <07465C1D981ABC41A344374066AE1A2C389F5D1382@TLVMBX01.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_07465C1D981ABC41A344374066AE1A2C389F5D1382TLVMBX01nicec_" MIME-Version: 1.0 Subject: [siprec] Summary of open items fron WGLC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 25 Jan 2011 01:30:57 -0000 --_000_07465C1D981ABC41A344374066AE1A2C389F5D1382TLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Following the summary from the mailing list of open items: 1. Remove REQ-15 and REQ-16. They relate to the policy mechanism or w= e can just to reword them to "stop" recording 2. Section 6: a. s/if caller does not trust/if the caller does not trust/ b. s/for what purpose can the recording be/for what purpose the record= ing can be/ 3. Abstract: "Recording is typically done by". Maybe could replace = "done" with "achieved" or "perfomed". 4. Definitions: only SRC can be source of the metadata 5. Section 4 use case 1: to remove statements all statements on "Red= undant" or "Duplicate" recording 6. Add new requirement: a. "The mechanism MUST support the ability to deliver to the SRS mult= iple media streams of the same media type (e.g. audio, video). For example = in the case of delivering unmixed audio for each participant in the CS". 7. Rewording of REQ-5: a. REQ-005 The mechanism MUST support the ability to record a CS with= out loss of media (for example, clipping media at the beginning of the CS) = due to RS recording preparation and also, without impacting the quality or = timing of the CS (for example, delaying the start of the CS while preparati= on for recording session). See Use Case 4 in Section 4 for more details. 8. Rewording: REQ-013 The mechanism MUST provide the SRS with the mea= ns to correlate RS media with CS participant media. 9. I recommend to delete REQ-021. Because we have 12 and 13 10. And John's editorial comments in his separate email. Leon --_000_07465C1D981ABC41A344374066AE1A2C389F5D1382TLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoPlainText, li.MsoPlainText, div.MsoPlainText {mso-style-priority:99; mso-style-link:"Plain Text Char"; margin:0cm; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0cm; margin-right:0cm; margin-bottom:0cm; margin-left:36.0pt; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} span.PlainTextChar {mso-style-name:"Plain Text Char"; mso-style-priority:99; mso-style-link:"Plain Text"; font-family:"Calibri","sans-serif";} .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif";} @page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 90.0pt 72.0pt 90.0pt;} div.WordSection1 {page:WordSection1;} /* List Definitions */ @list l0 {mso-list-id:944460882; mso-list-type:hybrid; mso-list-template-ids:-628467460 67698703 67698713 67698715 67698703 67698= 713 67698715 67698703 67698713 67698715;} @list l0:level1 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level2 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level3 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} @list l0:level4 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level5 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level6 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} @list l0:level7 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level8 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level9 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} ol {margin-bottom:0cm;} ul {margin-bottom:0cm;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>Following the su= mmary from the mailing list of open items:<o:p></o:p></p><p class=3DMsoNorm= al><o:p> </o:p></p><p class=3DMsoListParagraph style=3D'text-indent:-1= 8.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span style=3D'mso-list= :Ignore'>1.<span style=3D'font:7.0pt "Times New Roman"'>   &= nbsp;   </span></span><![endif]><span dir=3DLTR></span>Remove REQ= -15 and REQ-16. They relate to the policy mechanism or we can just to rewor= d them to "stop" recording<o:p></o:p></p><p class=3DMsoListParagr= aph style=3D'text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLis= ts]><span style=3D'mso-list:Ignore'>2.<span style=3D'font:7.0pt "Times New = Roman"'>       </span></span><![endif]><span = dir=3DLTR></span>Section 6: <o:p></o:p></p><p class=3DMsoPlainText style=3D= 'margin-left:72.0pt;text-indent:-18.0pt;mso-list:l0 level2 lfo1'><![if !sup= portLists]><span style=3D'mso-list:Ignore'>a.<span style=3D'font:7.0pt "Tim= es New Roman"'>       </span></span><![endif]= ><span dir=3DLTR></span>s/if caller does not trust/if the caller does not t= rust/<o:p></o:p></p><p class=3DMsoPlainText style=3D'margin-left:72.0pt;tex= t-indent:-18.0pt;mso-list:l0 level2 lfo1'><![if !supportLists]><span style= =3D'mso-list:Ignore'>b.<span style=3D'font:7.0pt "Times New Roman"'> &= nbsp;    </span></span><![endif]><span dir=3DLTR></span>s/fo= r what purpose can the recording be/for what purpose the recording can be/<= o:p></o:p></p><p class=3DMsoPlainText style=3D'margin-left:36.0pt;text-inde= nt:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span style=3D'mso= -list:Ignore'>3.<span style=3D'font:7.0pt "Times New Roman"'>  &n= bsp;    </span></span><![endif]><span dir=3DLTR></span> = ;Abstract: "Recording is typically done by". Maybe could replace =  "done" with "achieved" or "perfomed".<o= :p></o:p></p><p class=3DMsoPlainText style=3D'margin-left:36.0pt;text-inden= t:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span style=3D'mso-= list:Ignore'>4.<span style=3D'font:7.0pt "Times New Roman"'>  &nb= sp;    </span></span><![endif]><span dir=3DLTR></span>Defini= tions: only SRC can be source of the metadata<o:p></o:p></p><p class=3DMsoL= istParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !s= upportLists]><span style=3D'mso-list:Ignore'>5.<span style=3D'font:7.0pt "T= imes New Roman"'>       </span></span><![endi= f]><span dir=3DLTR></span>Section 4 use case 1:  to remove statements = all statements on "Redundant" or "Duplicate" recording<= o:p></o:p></p><p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-= list:l0 level1 lfo1'><![if !supportLists]><span style=3D'mso-list:Ignore'>6= .<span style=3D'font:7.0pt "Times New Roman"'>     = ;  </span></span><![endif]><span dir=3DLTR></span>Add new requirement:= <o:p></o:p></p><p class=3DMsoListParagraph style=3D'margin-left:72.0pt;tex= t-indent:-18.0pt;mso-list:l0 level2 lfo1'><![if !supportLists]><span style= =3D'mso-list:Ignore'>a.<span style=3D'font:7.0pt "Times New Roman"'> &= nbsp;     </span></span><![endif]><span dir=3DLTR></spa= n>"The mechanism MUST support the ability to deliver to the SRS multip= le media streams of the same media type (e.g. audio, video). For example in= the case of delivering unmixed audio for each participant in the CS".= <o:p></o:p></p><p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso= -list:l0 level1 lfo1'><![if !supportLists]><span style=3D'mso-list:Ignore'>= 7.<span style=3D'font:7.0pt "Times New Roman"'>    &nbs= p;  </span></span><![endif]><span dir=3DLTR></span>Rewording of REQ-5:= <o:p></o:p></p><p class=3DMsoListParagraph style=3D'margin-left:72.0pt;text= -indent:-18.0pt;mso-list:l0 level2 lfo1'><![if !supportLists]><span style= =3D'mso-list:Ignore'>a.<span style=3D'font:7.0pt "Times New Roman"'> &= nbsp;     </span></span><![endif]><span dir=3DLTR></spa= n>REQ-005 The mechanism MUST support the ability to record a CS without los= s of media (for example, clipping media at the beginning of the CS) due to = RS recording preparation and also, without impacting the quality or timing = of the CS (for example, delaying the start of the CS while preparation for = recording session). See Use Case 4 in Section 4 for more details.<o:p></o:p= ></p><p class=3DMsoPlainText style=3D'margin-left:36.0pt;text-indent:-18.0p= t;mso-list:l0 level1 lfo1'><![if !supportLists]><span style=3D'mso-list:Ign= ore'>8.<span style=3D'font:7.0pt "Times New Roman"'>    = ;   </span></span><![endif]><span dir=3DLTR></span>Rewording: REQ= -013 The mechanism MUST provide the SRS with the means to   corre= late RS media with CS participant media.<o:p></o:p></p><p class=3DMsoPlainT= ext style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo1= '><![if !supportLists]><span style=3D'mso-list:Ignore'>9.<span style=3D'fon= t:7.0pt "Times New Roman"'>       </span></sp= an><![endif]><span dir=3DLTR></span>I recommend to delete REQ-021. &nb= sp; Because we have 12 and 13<o:p></o:p></p><p class=3DMsoListParagraph sty= le=3D'text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><sp= an style=3D'mso-list:Ignore'>10.<span style=3D'font:7.0pt "Times New Roman"= '>   </span></span><![endif]><span dir=3DLTR></span>And John's ed= itorial comments in his separate email.<o:p></o:p></p><p class=3DMsoNormal>= <o:p> </o:p></p><p class=3DMsoNormal>Leon<o:p></o:p></p></div></body><= /html>= --_000_07465C1D981ABC41A344374066AE1A2C389F5D1382TLVMBX01nicec_-- From partr@cisco.com Mon Jan 24 21:46:41 2011 Return-Path: <partr@cisco.com> X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 398C53A690D for <siprec@core3.amsl.com>; Mon, 24 Jan 2011 21:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.142 X-Spam-Level: X-Spam-Status: No, score=-10.142 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aflTZx2yLIau for <siprec@core3.amsl.com>; Mon, 24 Jan 2011 21:46:33 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 7966F3A6B72 for <siprec@ietf.org>; Mon, 24 Jan 2011 21:46:33 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFAJPzPU1AaMHG/2dsb2JhbACCQaIxc6BRmzSFUASFFYpf Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-5.cisco.com with ESMTP; 25 Jan 2011 05:49:29 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0P5nNLT019870; Tue, 25 Jan 2011 05:49:25 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Jan 2011 11:19:23 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBBC53.7B5D6706" Date: Tue, 25 Jan 2011 11:18:26 +0530 Message-ID: <A11921905DA1564D9BCF64A6430A6239044BDAC0@XMB-BGL-411.cisco.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF7406989A96@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] draft-ram-siprec-metadata-format-00 for Review Thread-Index: Acu5mQo4RC5BhuXCQFOzg3WgV44EjAAABm26AJwiqMAAEmRB0A== References: <20110121182547.848C43A6A80@core3.amsl.com> <A11921905DA1564D9BCF64A6430A62390293A61A@XMB-BGL-411.cisco.com> <059AF07365DC474393A19A3AF187DF7406989A96@NAHALD.us.int.genesyslab.com> From: "Parthasarathi R (partr)" <partr@cisco.com> To: "Henry Lum" <Henry.Lum@alcatel-lucent.com>, <siprec@ietf.org> X-OriginalArrivalTime: 25 Jan 2011 05:49:23.0096 (UTC) FILETIME=[9E195980:01CBBC53] Subject: Re: [siprec] draft-ram-siprec-metadata-format-00 for Review X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 25 Jan 2011 05:46:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBBC53.7B5D6706 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Henry, =20 Thanks for your comment. I agree with you for partial metadata exchange. I'll update -01 version with partial notification of data. =20 Thanks Partha ________________________________ From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com]=20 Sent: Tuesday, January 25, 2011 3:02 AM To: Parthasarathi R (partr); siprec@ietf.org Subject: RE: [siprec] draft-ram-siprec-metadata-format-00 for Review Hi Partha, =20 This is a good start, and the main concern I have is the declarative nature of this format. Since metadata is delivered as a stream of events, so whenever something changes in the CS (ie. added a participant, or participant muted audio), would the SRC report the change by providing the entire declaration as a snapshot again? The problem I see here is the SRS would end up with the responsibility to figure out the changes made since the last snapshot. It's kind of like doing a diff against the previous snapshot if the SRS needs to know what the metadata event is about. =20 I am wondering if we can using something like the XCON event package although it's expired, and this is based on RFC5261 which uses XPath to locate and make changes to the snapshot. =20 Regards, Henry =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) Sent: Friday, January 21, 2011 1:42 PM To: siprec@ietf.org Subject: [siprec] draft-ram-siprec-metadata-format-00 for Review =20 Hi all, =20 Paul, Ram and myself have posted the initial Metadata format -00 draft based on Metadata model draft(draft-ram-siprec-metadata). Metadata format introduces new SIPREC metadata specific XML document and links to SDP for media parameters. The draft provides realization of Metadata model. =20 This draft is in initial stage with lot of open item. The basic idea of posting this draft is to get the high level consensus, start the discussion on interim meeting before deep dive into individual items. =20 Thanks Partha =20 ________________________________ From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Fri 1/21/2011 11:55 PM To: Parthasarathi R (partr) Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) Subject: New Version Notification for draft-ram-siprec-metadata-format-00=20 =20 A new version of I-D, draft-ram-siprec-metadata-format-00.txt has been successfully submitted by Parthasarathi R and posted to the IETF repository. Filename: draft-ram-siprec-metadata-format Revision: 00 Title: Session Initiation Protocol (SIP) Recording Metadata Format Creation_date: 2011-01-21 WG ID: Independent Submission Number_of_pages: 14 Abstract: 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. The requirements for which are described in [I-D.ietf-siprec-req], the architecture for which is described in [I-D.ietf-siprec-architecture], and the metadata model viewed by Session Recording Server is described in [I-D.ram-siprec-metadata]. This document focuses on the Recording metadata format which describes the communication session. =20 The IETF Secretariat. =20 CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.=20 ------_=_NextPart_001_01CBBC53.7B5D6706 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20 "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:x =3D=20 "urn:schemas-microsoft-com:office:excel" xmlns:p =3D=20 "urn:schemas-microsoft-com:office:powerpoint" xmlns:a =3D=20 "urn:schemas-microsoft-com:office:access" xmlns:dt =3D=20 "uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s =3D=20 "uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs =3D=20 "urn:schemas-microsoft-com:rowset" xmlns:z =3D "#RowsetSchema" xmlns:b = =3D=20 "urn:schemas-microsoft-com:office:publisher" xmlns:ss =3D=20 "urn:schemas-microsoft-com:office:spreadsheet" xmlns:c =3D=20 "urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc =3D=20 "urn:schemas-microsoft-com:office:odc" xmlns:oa =3D=20 "urn:schemas-microsoft-com:office:activation" xmlns:html =3D=20 "http://www.w3.org/TR/REC-html40" xmlns:q =3D=20 "http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc =3D=20 "http://microsoft.com/officenet/conferencing" XMLNS:D =3D "DAV:" = XMLNS:Repl =3D=20 "http://schemas.microsoft.com/repl/" xmlns:mt =3D=20 "http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2 =3D=20 "http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda =3D=20 "http://www.passport.com/NameSpace.xsd" xmlns:ois =3D=20 "http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir =3D=20 "http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds =3D=20 "http://www.w3.org/2000/09/xmldsig#" xmlns:dsp =3D=20 "http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc =3D=20 "http://schemas.microsoft.com/data/udc" xmlns:xsd =3D=20 "http://www.w3.org/2001/XMLSchema" xmlns:sub =3D=20 "http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec = =3D=20 "http://www.w3.org/2001/04/xmlenc#" xmlns:sp =3D=20 "http://schemas.microsoft.com/sharepoint/" xmlns:sps =3D=20 "http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi =3D=20 "http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs =3D=20 "http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf =3D=20 "http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p =3D=20 "http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf =3D=20 "http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss =3D=20 "http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi =3D=20 "http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi =3D=20 "http://schemas.openxmlformats.org/package/2006/digital-signature" = xmlns:mver =3D=20 "http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m = =3D=20 "http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels =3D=20 "http://schemas.openxmlformats.org/package/2006/relationships" = xmlns:spwp =3D=20 "http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t =3D=20 "http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m = =3D=20 "http://schemas.microsoft.com/exchange/services/2006/messages" = xmlns:pptsl =3D=20 "http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl = =3D=20 "http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksSe= rvice"=20 XMLNS:Z =3D "urn:schemas-microsoft-com:" xmlns:st =3D = "=01"><HEAD><TITLE>New Version Notification for = draft-ram-siprec-metadata-format-00
Hi Henry,
 
Thanks for your comment. I agree with you for=20 partial metadata exchange. I'll update -01 version with partial = notification of=20 data.
 
Thanks
Partha

From: Henry Lum=20 [mailto:Henry.Lum@alcatel-lucent.com]
Sent: Tuesday, January = 25, 2011=20 3:02 AM
To: Parthasarathi R (partr);=20 siprec@ietf.org
Subject: RE: [siprec]=20 draft-ram-siprec-metadata-format-00 for Review

Hi=20 Partha,

 

This=20 is a good start, and the main concern I have is the declarative nature = of this=20 format. Since metadata is delivered as a stream of events, so whenever = something=20 changes in the CS (ie. added a participant, or participant muted audio), = would=20 the SRC report the change by providing the entire declaration as a = snapshot=20 again? The problem I see here is the SRS would end up with the = responsibility to=20 figure out the changes made since the last snapshot. It’s kind of = like doing a=20 diff against the previous snapshot if the SRS needs to know what the = metadata=20 event is about.

 

I am=20 wondering if we can using something like the XCON event package although = it’s=20 expired, and this is based on RFC5261 which uses XPath to locate and = make=20 changes to the snapshot.

 

Regards,

Henry

 

From:=20 siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Parthasarathi R (partr)
Sent: Friday, January 21, 2011 = 1:42=20 PM
To: siprec@ietf.org
Subject: [siprec]=20 draft-ram-siprec-metadata-format-00 for = Review

 

Hi=20 all,

 

Paul, Ram = and=20 myself have posted the initial Metadata format -00 draft based on = Metadata=20 model draft(draft-ram-siprec-metadata). Metadata format introduces new = SIPREC=20 metadata specific XML document and links to SDP for media parameters. = The draft=20 provides realization of Metadata model.

 

This draft = is in=20 initial stage with lot of open item. The basic idea of posting this = draft is to=20 get the high level consensus, start the discussion on interim=20 meeting before deep dive into individual = items.

 

Thanks

Partha

 

From: IETF I-D = Submission=20 Tool [mailto:idsubmission@ietf.org]
Sent: Fri 1/21/2011 11:55=20 PM
To: Parthasarathi R (partr)
Cc: Ram Mohan R = (rmohanr);=20 Paul Kyzivat (pkyzivat)
Subject: New Version Notification for=20 draft-ram-siprec-metadata-format-00

 

A new = version of=20 I-D, draft-ram-siprec-metadata-format-00.txt has been successfully = submitted by=20 Parthasarathi R and posted to the IETF=20 repository.

Filename:       =20 draft-ram-siprec-metadata-format
Revision:    &nbs= p;  =20 00
Title:           = Session=20 Initiation Protocol (SIP) Recording Metadata=20 Format
Creation_date:   2011-01-21
WG ID: =20          Independent=20 Submission
Number_of_pages: 14

Abstract:
Session recording = is a=20 critical requirement in many communications
environments such as call = centers=20 and financial trading.  In some of
these environments, all calls = must be=20 recorded for regulatory,
compliance, and consumer protection = reasons. =20 Recording of a session
is typically performed by sending a copy of a = media=20 stream to a
recording device.  The requirements for which are = described=20 in
[I-D.ietf-siprec-req], the architecture for which is described=20 in
[I-D.ietf-siprec-architecture], and the metadata model viewed=20 by
Session Recording Server is described in=20 [I-D.ram-siprec-metadata].
This document focuses on the Recording = metadata=20 format which
describes the communication=20 session.
          &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =           


T= he=20 IETF Secretariat.

 


CONFIDENTIALITY=20 NOTICE: This e-mail and any files attached may contain confidential and=20 proprietary information of Alcatel-Lucent and/or its affiliated = entities. Access=20 by the intended recipient only is authorized. Any liability arising from = any=20 party acting, or refraining from acting, on any information contained in = this=20 e-mail is hereby excluded. If you are not the intended recipient, please = notify=20 the sender immediately, destroy the original transmission and its = attachments=20 and do not disclose the contents to any other person, use it for any = purpose, or=20 store or copy the information in any medium. Copyright in this e-mail = and any=20 attachments belongs to Alcatel-Lucent and/or its affiliated entities.=20 ------_=_NextPart_001_01CBBC53.7B5D6706-- From partr@cisco.com Mon Jan 24 21:49:36 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D57FA3A6B72 for ; Mon, 24 Jan 2011 21:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUslS2du2gum for ; Mon, 24 Jan 2011 21:49:35 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 1912C3A69AC for ; Mon, 24 Jan 2011 21:49:35 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAv0PU1AaMHG/2dsb2JhbACkcnOgVJs0hVAEhRWKXw Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 25 Jan 2011 05:52:30 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0P5pNN2020372; Tue, 25 Jan 2011 05:52:28 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Jan 2011 11:22:24 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Jan 2011 11:22:16 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Inputs to draft-ietf-siprec-req-06 Thread-Index: AcuyUfJnU/vECby9TGaM0uRbXItGhAC8g4WgABTj8SAAIgSUIAAANi2wAADxo7AABC4GcAAGsDKwACPaoVAAiivRkAAKrPkAAAA6kBAAEPRRwAAHdVJAAIHQnrAALelfgA== References: <07465C1D981ABC41A344374066AE1A2C389F44872A@TLVMBX01.nice.com> From: "Parthasarathi R (partr)" To: "Elwell, John" , "Dave Smith" , "Leon Portman" , X-OriginalArrivalTime: 25 Jan 2011 05:52:24.0554 (UTC) FILETIME=[0A41A4A0:01CBBC54] Subject: Re: [siprec] Inputs to draft-ietf-siprec-req-06 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 05:49:36 -0000 +1=20 -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Monday, January 24, 2011 1:28 PM To: Dave Smith; Leon Portman; Parthasarathi R (partr); siprec@ietf.org Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06 OK with me. John (as individual) > -----Original Message----- > From: Dave Smith [mailto:Dave.d.Smith@genesyslab.com] > Sent: 21 January 2011 18:01 > To: Leon Portman; Parthasarathi R (partr); Elwell, John;=20 > siprec@ietf.org > Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06 > > > My follow-on inputs inline below ( [DS] ). > > Regards, > Dave > > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: Monday, January 17, 2011 11:13 PM > To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > Cc: Dave Smith > Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06 > > Looking good > > Leon > > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) > Sent: Monday, January 17, 2011 4:35 PM > To: Elwell, John; siprec@ietf.org > Cc: Dave Smith > Subject: Re: [siprec] Inputs to draft-ietf-siprec-req-06 > > John/David, > > I'm fine with REQ-5 as long as the intention is to avoid initial=20 > clipping in recording using persistent RS or similar SIPREC proposed=20 > mechanism. Just, I'm trying to reword for this requirement: > > o REQ-005 The mechanism MUST support the ability to record a CS=20 > without loss of media (for example, clipping media at the beginning of > the CS) due to RS recording preparation and also, without impacting=20 > the quality or timing of the CS (for example, delaying the start of=20 > the CS while preparation for recording session). See Use Case 4 in=20 > Section > 4 for more > details. > > --- Removed: "intentional" > --- Added: "due to RS recording preparation and also" > > Please let me know your opinion. > > Thanks > Partha > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Monday, January 17, 2011 4:31 PM > To: Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06 > > > > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 17 January 2011 09:09 > > To: Elwell, John; siprec@ietf.org > > Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06 > > > > Please read inline > > > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: Monday, January 17, 2011 2:08 PM > > To: Elwell, John; siprec@ietf.org > > Subject: Re: [siprec] Inputs to draft-ietf-siprec-req-06 > > > > > > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > > Sent: 17 January 2011 08:23 > > > To: siprec@ietf.org > > > Subject: [siprec] FW: Inputs to draft-ietf-siprec-req-06 > > > > > > Forwarded on behalf of Dave Smith. > > > > > > > -----Original Message----- > > > > From: Dave Smith [mailto:Dave.Smith@genesyslab.com] > > > > Sent: 16 January 2011 16:08 > > > > To: Elwell, John > > > > Subject: FW: Inputs to draft-ietf-siprec-req-06 > > > > > > > > Hi John, > > > > > > > > Can you please send this email out to the > "siprec@ietf.org" email > > > > address for me. > > > > Our Genesys email server is failing to send emails out to > > > that address > > > > again (in the mean time I will try to get it fixed through our=20 > > > > HelpDesk). > > > > > > > > Thanks, > > > > Dave > > > > > > > > > > > > -----Original Message----- > > > > From: Dave Smith > > > > Sent: Saturday, January 15, 2011 10:59 PM > > > > To: Elwell, John; siprec@ietf.org > > > > Subject: Inputs to draft-ietf-siprec-req-06 > > > > > > > > Here are my inputs to the latest draft-ietf-siprec-req-06. > > > > > > > > > > > > 1. Recommend to change this: > > > > o REQ-005 The mechanism MUST support the ability to > record a CS > > > > without an intentional loss of media (for example, > > clipping media > > > > > > at > > > > the beginning of the CS) and without impacting the > quality or > > > > timing > > > > of the CS (for example, delaying the start of the CS while > > > > preparation for recording takes place). See Use Case 4 in=20 > > > > Section 5. > > > > > > > > To this: > > > > o REQ-005 The mechanism MUST support the ability to > record a CS > > > > without an unintentional loss of media (for example, > > > clipping media > > > > at > > > > the beginning of the CS) and without impacting the > quality or > > > > timing > > > > of the CS (for example, delaying the start of the CS while > > > > preparation for recording takes place). > > > > > > > > The use case is not referenced correctly and I don't see > > > any reason to > > > > refer to it (doesn't provide much additional info). Also > > corrected > > > > "intentional" to "unintentional." > > [JRE] The word "intentional" came from me a few months ago. > Perhaps it > > was the wrong word - I was trying to convey the fact that some=20 > > mechanism might frequently lead to clipping - the loss of media is > kind of built > > into the mechanism, so in that sense it would be "intentional". I=20 > > don't think changing to "unintentional" is correct - we can't avoid=20 > > unintentional loss of media, e.g., through packet loss. I guess what > > we are really trying to achieve is something like this: "The=20 > > mechanism MUST support the ability to record a CS without loss of=20 > > media while preparation for recording takes place." > > > > IMO, without any loss of media may lead to > inefficient system > > in few deployment. For example, CS dialog is established > whereas RS is > > taking more time to establish due to network delay between SRC and=20 > > SRS, then it may be preferred in few deployment to loss some media=20 > > instead of delaying CS establishment and some other deployment may > prefer to wait > > for RS establishment. The current requirement wording indicates that > > CS dialog establishment MUST be delayed for RS establishment. > > [JRE] No, I believe it was not intended to force the CS to be delayed. > A mechanism that would meet this requirement without delaying CS=20 > establishment would be to keep an RS permanently established, even=20 > when there is no CS, so that it can immediately be used when a new CS=20 > starts. > This was the persistent recording use case (4), which I believe some=20 > people felt was needed for some environments, and hence the desire to=20 > capture requirements that such environments have. Clearly we have=20 > failed to capture that requirements adequately - we need the right=20 > words. > > John (as individual) > > [DS] > I agree with John's new wording, and that for this document we should > simplify and state: o REQ-005 "The mechanism MUST support > the ability > to record a CS without loss of RS media while preparation for=20 > recording takes place." > Although in a future version we might want to consider this area=20 > further. > [DS] > > > > > > > > > 2. Recommend to change this: > > > > o REQ-018 The mechanism MUST provide a means of > > indicating to the > > > > participants involved in a CS that their session is > > > being recorded. > > > > > > > > Examples include: inject tones into the CS from the > SRC, play a > > > > message at the beginning of a session, a visual > indicator on a > > > > display, etc. > > > > > > > > To this: > > > > o REQ-018 The mechanism MUST provide a means of > > indicating to the > > > > participants involved in a CS that their session is > > > currently being > > > > recorded. > > > > > > > > Examples include: inject tones into the CS from the > > SRC, a visual > > > > > > indicator on a display > > > > > > > > Added word "currently" because this is about providing > an ongoing > > > > indicator during the call. Removed the "play a > message...." part > > > > because playing a message at the beginning of a session > is not a > > > > method that would require a siprec protocol solution, > > it's n/a, it's > > > > > > not about " an ongoing indicator." > > [JRE] The word "currently" was there, in my opinion, > because playing a > > message to indicate that recording might take place at some stage=20 > > during the CS is what frequently happens and is sufficient for=20 > > regulatory purposes in some jurisdictions. I agree it would not > require a SIPREC > > protocol solution. Let's see what others say. > > I agree with John that playing a message meet some of the=20 > > Jurisdictions requirement. I like to hear from Dave whether any=20 > > jurisdiction mandates for "injection tone" or "visual display". > > > > > [DS] I believe that informing ahead of time (that is, to indicate=20 > that recording might take place at some stage during the CS) has=20 > nothing to do with SIPREC. If that is a suitable solution for this=20 > req't then I believe we should drop the req't entirely. > However, I see two reasons for functionality indicating that recording > is "currently" going on. And although I do not know of any=20 > regulations requiring this functionality, I believe it is important. =20 > The reasons > are: In order to inform (1) agents, and/or (2) customers that a call=20 > is "currently" being recorded. > For many Customers, I believe that playing a message up-front via an=20 > IVR (for example) to "inform" them that "a call may be recorded..."=20 > may not be enough and that it would be desirable to also provide an=20 > ongoing indicator if recording is actually occurring "currently." > Also, there > are many examples where companies/environments want to be able to=20 > inform their Agents when a call is "currently being recorded". [DS] > > > > Thanks > > Partha > > > > John (as individual) > > > > > > > > > > > > > > 3. Recommend to change this: > > > > o REQ-013 The mechanism MUST provide the SRS with > the means to > > > > correlate RS media with CS participant media described > > > in metadata. > > > > > > > > To this: > > > > o REQ-013 The mechanism MUST provide the SRS with > the means to > > > > correlate RS media with CS participant media. > > > > > > > > This is recommended because I don't see the need for the > > part that > > > > read "described in metadata" and because it is not > clear what it > > > > meant. > > > > > > [DS] I recommend to drop the wording "described in metadata" in > REQ-013. [DS] > > > > > > > > > 4. Recommend to delete this Requirement: > > > > o REQ-021 The mechanism MUST support means to relate > Recording > > > > Session(s) with Communication Session(s). > > > > > > > > It is not needed since we have REQ-012 and REQ-013. > > > > > [DS] I recommend to delete REQ-021. [DS] > > > > > > > > > > > > Regards, > > > > Dave > > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > > > Sent: Wednesday, January 12, 2011 4:12 AM > > > > To: siprec@ietf.org > > > > Subject: [siprec] Agenda requests plus reminder > > > > > > > > Please let me have your agenda requests for the dual interim on=20 > > > > 25th/26th. > > > > > > > > Also, a reminder that WGLC on siprec-req is into its second > > > week and I > > > > have not seen any responses yet. Even if you are happy > with it as > > > > is, a note to the list would be helpful. > > > > > > > > John > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > -------------------------------------------------------------- > > > > ---------- > > > > ------------------------------------------- > > > > CONFIDENTIALITY NOTICE: This e-mail and any files attached > > > may contain > > > > confidential and proprietary information of Alcatel-Lucent > > > and/or its > > > > affiliated entities. Access by the intended recipient only is=20 > > > > authorized. Any liability arising from any party acting, or > > > refraining > > > > from acting, on any information contained in this e-mail > > is hereby > > > > excluded. If you are not the intended recipient, please > > notify the > > > > sender immediately, destroy the original transmission and its=20 > > > > attachments and do not disclose the contents to any > other person, > > > > use it for any purpose, or store or copy the information in any=20 > > > > medium. > > > > Copyright in this e-mail and any attachments belongs to > > > Alcatel-Lucent > > > > and/or its affiliated entities. > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > ----------------------------------------------------- > > > > CONFIDENTIALITY NOTICE: This e-mail and any files attached may=20 > > > > contain confidential and proprietary information of > > Alcatel-Lucent > > > > and/or its affiliated entities. Access by the intended > recipient > > > > only is authorized. Any liability arising from any party > > acting, or > > > > refraining from acting, on any information contained in > > this e-mail > > > > is hereby excluded. If you are not the intended > recipient, please > > > > notify the sender immediately, destroy the original > > transmission and > > > > > > its attachments and do not disclose the contents to any other=20 > > > > person, use it for any purpose, or store or copy the > > information in > > > > any medium. Copyright in this e-mail and any attachments > > belongs to > > > > Alcatel-Lucent and/or its affiliated > > > entities. > > > > > > > > > > > _______________________________________________ > > > 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 > > > -------------------------------------------------------------- > ----------------------------------------------------- > CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain > confidential and proprietary information of Alcatel-Lucent and/or its=20 > affiliated entities. Access by the intended recipient only is=20 > authorized. Any liability arising from any party acting, or refraining > from acting, on any information contained in this e-mail is hereby=20 > excluded. If you are not the intended recipient, please notify the=20 > sender immediately, destroy the original transmission and its=20 > attachments and do not disclose the contents to any other person, use=20 > it for any purpose, or store or copy the information in any medium.=20 > Copyright in this e-mail and any attachments belongs to Alcatel-Lucent > and/or its affiliated entities. > > From partr@cisco.com Mon Jan 24 21:53:05 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEA6A3A6B75 for ; Mon, 24 Jan 2011 21:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.161 X-Spam-Level: X-Spam-Status: No, score=-10.161 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z08MOsqwwJ80 for ; Mon, 24 Jan 2011 21:53:04 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 127F43A6B72 for ; Mon, 24 Jan 2011 21:53:04 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADf1PU1AaMHG/2dsb2JhbACkcnOgT5s0hVAEhRWKXw Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 25 Jan 2011 05:55:51 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0P5tPNl021464; Tue, 25 Jan 2011 05:55:45 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Jan 2011 11:25:25 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Jan 2011 11:24:30 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Extension to WGLC for siprec-req Thread-Index: Acu3JYIeO0vv8RdvT36l5TlpmKsJ8wFLp58A References: From: "Parthasarathi R (partr)" To: "Elwell, John" , X-OriginalArrivalTime: 25 Jan 2011 05:55:25.0576 (UTC) FILETIME=[76276880:01CBBC54] Cc: Leon Portman Subject: Re: [siprec] Extension to WGLC for siprec-req X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 05:53:05 -0000 Apart from Leon mentioned comments, the draft looks good and covers all the required requirements. Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John Sent: Tuesday, January 18, 2011 9:07 PM To: siprec@ietf.org Subject: [siprec] Extension to WGLC for siprec-req There was a disappointingly poor response to WGLC, which ended yesterday. Therefore the chairs have decided to extend WGLC until next Monday, 2011-01-24 (i.e., to finish the day before the interim virtual meeting). Please submit your comments and/or indicate whether you consider the document ready to go by that date. John _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From krehor@cisco.com Mon Jan 24 21:53:28 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7EE13A69AC for ; Mon, 24 Jan 2011 21:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHUBfgeckaBr for ; Mon, 24 Jan 2011 21:53:27 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 965653A690D for ; Mon, 24 Jan 2011 21:53:27 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAL70PU2rRN+J/2dsb2JhbACkcnOgUJs0hVAEhReKXQ Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 25 Jan 2011 05:56:24 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p0P5uOt2002624; Tue, 25 Jan 2011 05:56:24 GMT Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Jan 2011 21:56:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Jan 2011 21:56:21 -0800 Message-ID: <7744FE52C78D944587F03773EB4514610947F3AF@xmb-sjc-22e.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Extension to WGLC for siprec-req Thread-Index: Acu3JYIeO0vv8RdvT36l5TlpmKsJ8wFLp58AAAAa2nA= References: From: "Ken Rehor (krehor)" To: "Parthasarathi R (partr)" , "Elwell, John" , X-OriginalArrivalTime: 25 Jan 2011 05:56:24.0438 (UTC) FILETIME=[993D0960:01CBBC54] Cc: Leon Portman Subject: Re: [siprec] Extension to WGLC for siprec-req X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 05:53:28 -0000 +1 > -----Original Message----- > From: Parthasarathi R (partr) > Sent: Monday, January 24, 2011 9:55 PM > To: Elwell, John; siprec@ietf.org > Cc: Ken Rehor (krehor); Leon Portman > Subject: RE: [siprec] Extension to WGLC for siprec-req >=20 > Apart from Leon mentioned comments, the draft looks good and covers all the > required requirements. >=20 > Thanks > Partha From rmohanr@cisco.com Mon Jan 24 23:03:14 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29F943A6A5C for ; Mon, 24 Jan 2011 23:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.473 X-Spam-Level: X-Spam-Status: No, score=-10.473 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87bADtOgWFqp for ; Mon, 24 Jan 2011 23:03:12 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A8C803A6A5D for ; Mon, 24 Jan 2011 23:03:11 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADAFPk1AaMHG/2dsb2JhbACkc3OhCZs1hVAEhRWKXw Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-1.cisco.com with ESMTP; 25 Jan 2011 07:06:07 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0P75rRx011078; Tue, 25 Jan 2011 07:06:06 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Jan 2011 12:36:04 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Jan 2011 12:36:01 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD05124A10@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Extension to WGLC for siprec-req Thread-Index: Acu3JYIeO0vv8RdvT36l5TlpmKsJ8wFLp58AAABWnvA= References: From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , X-OriginalArrivalTime: 25 Jan 2011 07:06:04.0923 (UTC) FILETIME=[55006CB0:01CBBC5E] Cc: Leon Portman Subject: Re: [siprec] Extension to WGLC for siprec-req X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 07:03:14 -0000 +1 Apart from the comments that Leon summarized in his mail, the draft looks good to go. Thanks, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Parthasarathi R (partr) > Sent: Tuesday, January 25, 2011 11:25 AM > To: Elwell, John; siprec@ietf.org > Cc: Leon Portman > Subject: Re: [siprec] Extension to WGLC for siprec-req >=20 > Apart from Leon mentioned comments, the draft looks good and covers all > the required requirements. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > Of Elwell, John > Sent: Tuesday, January 18, 2011 9:07 PM > To: siprec@ietf.org > Subject: [siprec] Extension to WGLC for siprec-req >=20 > There was a disappointingly poor response to WGLC, which ended > yesterday. Therefore the chairs have decided to extend WGLC until next > Monday, 2011-01-24 (i.e., to finish the day before the interim virtual > meeting). Please submit your comments and/or indicate whether you > consider the document ready to go by that date. >=20 > John > _______________________________________________ > 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 From john.elwell@siemens-enterprise.com Mon Jan 24 23:35:12 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A2E43A6A60 for ; Mon, 24 Jan 2011 23:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzw+zqpBq+17 for ; Mon, 24 Jan 2011 23:35:11 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id C19B93A6A20 for ; Mon, 24 Jan 2011 23:35:10 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3130849; Tue, 25 Jan 2011 08:38:05 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 703F623F0278; Tue, 25 Jan 2011 08:38:02 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 25 Jan 2011 08:38:03 +0100 From: "Elwell, John" To: Leon Portman , "siprec@ietf.org" Date: Tue, 25 Jan 2011 08:38:01 +0100 Thread-Topic: [siprec] Summary of open items fron WGLC Thread-Index: Acu8LgmM3YpmHvKvQpybOZYKNtoI1wANKMWg Message-ID: References: <07465C1D981ABC41A344374066AE1A2C389F5D1382@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C389F5D1382@TLVMBX01.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Summary of open items fron WGLC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 07:35:12 -0000 I guess the editors will cover some of these during today's call, but if an= yone has any concerns about the proposed changes, please shout as soon as p= ossible. John (as chair)=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman > Sent: 25 January 2011 01:34 > To: siprec@ietf.org > Subject: [siprec] Summary of open items fron WGLC >=20 > Following the summary from the mailing list of open items: >=20 > =20 >=20 > 1. Remove REQ-15 and REQ-16. They relate to the policy=20 > mechanism or we can just to reword them to "stop" recording >=20 > 2. Section 6:=20 >=20 > a. s/if caller does not trust/if the caller does not trust/ >=20 > b. s/for what purpose can the recording be/for what=20 > purpose the recording can be/ >=20 > 3. Abstract: "Recording is typically done by". Maybe=20 > could replace "done" with "achieved" or "perfomed". >=20 > 4. Definitions: only SRC can be source of the metadata >=20 > 5. Section 4 use case 1: to remove statements all=20 > statements on "Redundant" or "Duplicate" recording >=20 > 6. Add new requirement:=20 >=20 > a. "The mechanism MUST support the ability to deliver=20 > to the SRS multiple media streams of the same media type=20 > (e.g. audio, video). For example in the case of delivering=20 > unmixed audio for each participant in the CS". >=20 > 7. Rewording of REQ-5: >=20 > a. REQ-005 The mechanism MUST support the ability to=20 > record a CS without loss of media (for example, clipping=20 > media at the beginning of the CS) due to RS recording=20 > preparation and also, without impacting the quality or timing=20 > of the CS (for example, delaying the start of the CS while=20 > preparation for recording session). See Use Case 4 in Section=20 > 4 for more details. >=20 > 8. Rewording: REQ-013 The mechanism MUST provide the=20 > SRS with the means to correlate RS media with CS participant media. >=20 > 9. I recommend to delete REQ-021. Because we have 12 and 13 >=20 > 10. And John's editorial comments in his separate email. >=20 > =20 >=20 > Leon >=20 > = From krehor@cisco.com Tue Jan 25 00:34:50 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 958B83A6B84 for ; Tue, 25 Jan 2011 00:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.209 X-Spam-Level: X-Spam-Status: No, score=-10.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xZ83gf6WjXC for ; Tue, 25 Jan 2011 00:34:46 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 6A4453A63D2 for ; Tue, 25 Jan 2011 00:34:44 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: draft-ietf-siprec-req-07.txt : 31971 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAP8aPk2Q/khLgWdsb2JhbACkcxYBFiIkoSCMJ48WgneCWASFF3KJa4h/ Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 25 Jan 2011 08:37:34 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p0P8ZHLq026121; Tue, 25 Jan 2011 08:37:33 GMT Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Jan 2011 00:36:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CBBC6A.FB1B5063" Date: Tue, 25 Jan 2011 00:36:34 -0800 Message-ID: <7744FE52C78D944587F03773EB4514610947F3F2@xmb-sjc-22e.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] WGLC comments on siprec-req-06 Thread-Index: Acu2YyIsRf9CmsUSTiKw4g9xxHZSWAF/sFmw References: From: "Ken Rehor (krehor)" To: "Elwell, John" , X-OriginalArrivalTime: 25 Jan 2011 08:36:38.0327 (UTC) FILETIME=[FB901470:01CBBC6A] Subject: Re: [siprec] WGLC comments on siprec-req-06 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 08:34:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBBC6A.FB1B5063 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft of -07 attached, including changes noted below and in Leon's email of 24 Jan. Ken > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of > Elwell, John > Sent: Monday, January 17, 2011 8:25 AM > To: siprec@ietf.org > Subject: [siprec] WGLC comments on siprec-req-06 >=20 > My WGLC comments (as individual). >=20 > I think the document is almost ready to go, but needs the following minor > points and nits fixing. >=20 > Minor: > 1. Abstract: > "This document specifies requirements for > extensions to SIP that will manage delivery of RTP media from an end- > point that originates media (or that has access to it) to a recording > device." > The words "end-point" and "originates" are not really suitable where the > SRC is at a B2BUA. I would suggest rewording as: > "This document specifies requirements for extensions to SIP that will > manage delivery of RTP media to a recording device." [ ] done. =20 > 2. Section 3: > "An SRS is a logical > function that typically archives media for extended durations of time > and provides interfaces for search and retrieval of the archived > media." > I don't think the SRS provides such interfaces. Such interfaces would be > available, but I don't think they should be considered part of the SRS. > Also I don't think the word "typically" is necessary. I would suggest a > reword as follows: > "An SRS is a logical function that archives media for extended periods. > Other functions can provide interfaces for searching and retrieving > archived media." [ ] I think this is too implementation-specific. I suggest we just remove the sentences regarding archiving and retrieval of media. =20 > 3. Section 3: > "An SRS is typically implemented as a multi-port device that > is capable of receiving media from several sources simultaneously." > The word "several" seems to suggest a small number. I would suggest we > change "several" to "multiple". [ ] done. =20 > 4. Section 3: > "An SRS is typically also the sink of the recorded session metadata." > Delete the word "typically" - I don't think we have any other model in > mind. [ ] done. =20 > 5. Section 3: > "Communication Session (CS): A session created between two or more SIP > User Agents (UAs) that is the target for recording." > Change "target for recording" to "subject of recording". [ ] done. =20 > 6. Section 4: > As a general comment, there are several incomplete sentences, e.g.: > - Use case 3 "One or more Recording Sessions per Communication Session:" > (no verb) [ ] This was actually supposed to be a description of the diagram, but it doesn't read that way so I've fixed it. > - Use case 9 "Record a call that is associated with another call." (no > subject) [ ] cleaned up entire description of use case. > - Use case 12 "Recording and real-time analytics of trading floor > interactions > (including video and instant messaging)." (no verb) [ ] cleaned up entire description of use case. =20 > 7. Section 4, use case 4: > "or in > parallel (Fig. 7)" > The figure number is wrong (should be figure 6), but I suggest we delete > these words. The subject of parallel CSs is introduced in the paragraph > immediately preceding figure 6, so we don't need to mention it here. [ ] done. >=20 > 8. Section 4, use case 4: > "A Recording Session records continuously without interruption. > Silent periods must be reproduced upon playback (e.g. by recording > the silent period, by not recording the silent periods but marking > them as metadata for a player to utilize, etc.)" > I think the point we are trying to make with use case 4 is that the RS > exists even when there is no CS - so it is more than just a silent period. > I would reword as: > "A Recording Session records continuously without interruption. Periods > when there is no CS in progress must be reproduced upon playback (e.g. by > recording silence during such periods or by not recording such periods but > marking them by means of metadata for utilization on playback, etc.)." >=20 > 9. Section 4, use case 4: > "The connection and attributes of media in the Recording Session are > not dynamically signaled for each Communication Session before it can > be recorded; however, codec re-negotiation is possible. CS details > and CS metadata will still be signaled, and can be correlated to the > recorded media. There will still need to be a means of correlating > the recorded media connection/packets to the Communication Session." > I think the whole paragraph is getting into solution and could be omitted. [ ] done. =20 > 10. Section 4, use case 5: > "One solution is to not record a caller > speaking their credit card information." > Why is not recording just one solution to "not capturing" (in the first > sentence of the paragraph)? It seems to me it is the ONLY solution. Clearly > you could record and then prevent playback, but then you have captured the > information. [ ] PCI compliance is just one example of an application that may require=20 protecting customer information. Not capturing that information is one way to protect it. Other possible solutions include encryption or post-call redaction. =20 > 11. Section 4, use case 7: > "Many agents and enterprise workers are not located on company > premises." > To make it clearer: > "Many agents and enterprise workers whose calls are to be recorded are not > located on company > premises." [ ] Done. =20 > 12. Section 4, use case 8: > "Internal calls inside or between branches must be recorded." > Why do only internal calls need recording? Should it say: > "Internal calls inside or between branches must be recorded, as well as > calls involving the central office and external calls." >=20 > 13. Section 4, use case 8: > "Global banks with multiple branches up to thousands of small sites. > o Only phones and network infrastructure in branches, no recording > services. > o Internal calls inside or between branches must be recorded. > o Centralized recording system in data centers together with > telephony infrastructure (e.g. PBX)." > The three bullets don't seem to form a coherent set. The first and last > describe the topology and the second describes recording needs. [ ] Reworded: Enterprises such as banks, insurance agencies, and retail stores may have many locations,=20 possibly up to thousands of small sites. Frequently only phones and network infrastructure are installed in branches, without local recording services. In cases where calls inside or between=20 branches must be recorded, a centralized recording system in data centers together with telephony infrastructure (e.g. PBX) me deployed. =20 > 14. Section 4, use case 9: > "Record a call that is associated with another call." > Apart from the fact this is not a complete sentence (see earlier comment), > I think the point we should be making is that both calls are recorded, > together with some means of associating them. [ ] reworded. =20 > 15. Section 4, use case 10: > "o The Communication Session must be terminated (or suitable > notification) in the event of a recording failure." > Change "or suitable notification" to "or suitable notification given to > parties". [ ] done. > 16. Section 4, use case 11: > "In trading floors environments, in order to save resources, it may be > preferable to mix multiple concurrent calls (Communication Sessions) > on different handsets/speakers on the same turret into single > recording session." > It is unclear what resources this really saves, unless you also mix the > media from the several CSs into a single media stream on the RS. Some > clarification would be useful. [ ] clarified that the resources are storage and recording system resources. =20 > 17. Section 4, use case 12: > "Recorder must support real-time media processing, such as speech > analytics." > I think this should say "It must be possible for a recorder to support...". [ ] done. =20 >=20 > Nits: > 18. Expand the following acronyms on first use: DTMF, ASR. [ ] removed acronyms (unnecessary detail) =20 > 19. Section 4, use case 4: > "in sequence (Fig. 6)" > This should be figure 5. [ ] fixed as part of earlier change (above) =20 > 20. Section 4, use case 4: > "The length of a Persistent Recording Sessions " > Change "Sessions" to "Session". [ ] done. =20 > 21. Section 4, use case 7: > "i.e. insurance agents, > brokers, physicians." > Change "i.e." to "e.g.". [ ] done. =20 > 22. Section 4, use case 11: > "Media is synchronized" > Change "is" to "are". [ ] done. =20 > 23. Section 4, use case 12: > "(stopping interaction or alert)" > Change "alert" to "alerting". [ ] done. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_001_01CBBC6A.FB1B5063 Content-Type: text/plain; name="draft-ietf-siprec-req-07.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-siprec-req-07.txt Content-Disposition: attachment; filename="draft-ietf-siprec-req-07.txt" CgoKRElTUEFUQ0ggICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBLLiBSZWhvciwgRWQuCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgQ2lzY28gU3lzdGVtcwpJbnRlbmRlZCBzdGF0dXM6IEluZm9y bWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICBMLiBQb3J0bWFuLCBFZC4KRXhwaXJl czogSnVseSAyOSwgMjAxMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTklD RSBTeXN0ZW1zCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEEuIEh1dHRvbgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBTaWVtZW5zIEVudGVycHJpc2UgQ29tbXVuaWNhdGlvbnMKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSLiBKYWlu CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBJUEMgU3lzdGVtcwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEphbnVhcnkgMjUsIDIwMTEKCgogICAgICAgICAgUmVxdWlyZW1lbnRz IGZvciBTSVAtYmFzZWQgTWVkaWEgUmVjb3JkaW5nIChTSVBSRUMpCiAgICAgICAgICAgICAgICAg ICAgICAgIGRyYWZ0LWlldGYtc2lwcmVjLXJlcS0wNwoKQWJzdHJhY3QKCiAgIFNlc3Npb24gcmVj b3JkaW5nIGlzIGEgY3JpdGljYWwgcmVxdWlyZW1lbnQgaW4gbWFueSBidXNpbmVzcwogICBjb21t dW5pY2F0aW9ucyBlbnZpcm9ubWVudHMgc3VjaCBhcyBjYWxsIGNlbnRlcnMgYW5kIGZpbmFuY2lh bAogICB0cmFkaW5nIGZsb29ycy4gIEluIHNvbWUgb2YgdGhlc2UgZW52aXJvbm1lbnRzLCBhbGwg Y2FsbHMgbXVzdCBiZQogICByZWNvcmRlZCBmb3IgcmVndWxhdG9yeSBhbmQgY29tcGxpYW5jZSBy ZWFzb25zLiAgSW4gb3RoZXJzLCBjYWxscyBtYXkKICAgYmUgcmVjb3JkZWQgZm9yIHF1YWxpdHkg Y29udHJvbCBvciBidXNpbmVzcyBhbmFseXRpY3MuCgogICBSZWNvcmRpbmcgaXMgdHlwaWNhbGx5 IHBlcmZvcm1lZCBieSBzZW5kaW5nIGEgY29weSBvZiB0aGUgc2Vzc2lvbgogICBtZWRpYSB0byB0 aGUgcmVjb3JkaW5nIGRldmljZXMuICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyByZXF1aXJlbWVu dHMKICAgZm9yIGV4dGVuc2lvbnMgdG8gU0lQIHRoYXQgd2lsbCBtYW5hZ2UgZGVsaXZlcnkgb2Yg UlRQIG1lZGlhIHRvIGEKICAgcmVjb3JkaW5nIGRldmljZS4gIFRoaXMgaXMgYmVpbmcgcmVmZXJy ZWQgdG8gYXMgU0lQLWJhc2VkIE1lZGlhCiAgIFJlY29yZGluZy4KClN0YXR1cyBvZiB0aGlzIE1l bW8KCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFu Y2Ugd2l0aCB0aGUKICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIEludGVy bmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVy aW5nCiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxz byBkaXN0cmlidXRlCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRo ZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtCiAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBk cmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBt YXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMg YXQgYW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFm dHMgYXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFz ICJ3b3JrIGluIHByb2dyZXNzLiIKCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUg b24gSnVseSAyOSwgMjAxMS4KCkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoYykgMjAx MSBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQoKCgpSZWhvciwg ZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAyOSwgMjAxMSAgICAgICAgICAgICAgICAg W1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgUmVxdWlyZW1lbnRzIGZvciBTSVBS RUMgICAgICAgICAgICBKYW51YXJ5IDIwMTEKCgogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJp Z2h0cyByZXNlcnZlZC4KCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5k IHRoZSBJRVRGIFRydXN0J3MgTGVnYWwKICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERv Y3VtZW50cwogICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZl Y3Qgb24gdGhlIGRhdGUgb2YKICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFz ZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzCiAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5 b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdAogICB0byB0aGlzIGRvY3Vt ZW50LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdAog ICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2Vj dGlvbiA0LmUgb2YKICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRl ZCB3aXRob3V0IHdhcnJhbnR5IGFzCiAgIGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0Qg TGljZW5zZS4KCiAgIFRoaXMgZG9jdW1lbnQgbWF5IGNvbnRhaW4gbWF0ZXJpYWwgZnJvbSBJRVRG IERvY3VtZW50cyBvciBJRVRGCiAgIENvbnRyaWJ1dGlvbnMgcHVibGlzaGVkIG9yIG1hZGUgcHVi bGljbHkgYXZhaWxhYmxlIGJlZm9yZSBOb3ZlbWJlcgogICAxMCwgMjAwOC4gIFRoZSBwZXJzb24o cykgY29udHJvbGxpbmcgdGhlIGNvcHlyaWdodCBpbiBzb21lIG9mIHRoaXMKICAgbWF0ZXJpYWwg bWF5IG5vdCBoYXZlIGdyYW50ZWQgdGhlIElFVEYgVHJ1c3QgdGhlIHJpZ2h0IHRvIGFsbG93CiAg IG1vZGlmaWNhdGlvbnMgb2Ygc3VjaCBtYXRlcmlhbCBvdXRzaWRlIHRoZSBJRVRGIFN0YW5kYXJk cyBQcm9jZXNzLgogICBXaXRob3V0IG9idGFpbmluZyBhbiBhZGVxdWF0ZSBsaWNlbnNlIGZyb20g dGhlIHBlcnNvbihzKSBjb250cm9sbGluZwogICB0aGUgY29weXJpZ2h0IGluIHN1Y2ggbWF0ZXJp YWxzLCB0aGlzIGRvY3VtZW50IG1heSBub3QgYmUgbW9kaWZpZWQKICAgb3V0c2lkZSB0aGUgSUVU RiBTdGFuZGFyZHMgUHJvY2VzcywgYW5kIGRlcml2YXRpdmUgd29ya3Mgb2YgaXQgbWF5CiAgIG5v dCBiZSBjcmVhdGVkIG91dHNpZGUgdGhlIElFVEYgU3RhbmRhcmRzIFByb2Nlc3MsIGV4Y2VwdCB0 byBmb3JtYXQKICAgaXQgZm9yIHB1YmxpY2F0aW9uIGFzIGFuIFJGQyBvciB0byB0cmFuc2xhdGUg aXQgaW50byBsYW5ndWFnZXMgb3RoZXIKICAgdGhhbiBFbmdsaXNoLgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKUmVob3IsIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjksIDIw MTEgICAgICAgICAgICAgICAgIFtQYWdlIDJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIFJl cXVpcmVtZW50cyBmb3IgU0lQUkVDICAgICAgICAgICAgSmFudWFyeSAyMDExCgoKVGFibGUgb2Yg Q29udGVudHMKCiAgIDEuICBSZXF1aXJlbWVudHMgbm90YXRpb24gIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNAogICAyLiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQKICAgMy4gIERlZmluaXRp b25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1 CiAgIDQuICBVc2UgQ2FzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgNwogICA1LiAgUmVxdWlyZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTEKICAgNi4gIFByaXZhY3kgQ29uc2lkZXJh dGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzCiAgIDcuICBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAxNAogICA4LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMTUKICAgOS4gIEFja25vd2xlZGdlbWVudHMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE1CiAgIDEwLiBOb3JtYXRpdmUg UmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNQog ICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTUKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpSZWhv ciwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAyOSwgMjAxMSAgICAgICAgICAgICAg ICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgUmVxdWlyZW1lbnRzIGZvciBT SVBSRUMgICAgICAgICAgICBKYW51YXJ5IDIwMTEKCgoxLiAgUmVxdWlyZW1lbnRzIG5vdGF0aW9u CgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxM IiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIs ICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRl cnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldIGFuZCBpbmRpY2F0ZQogICByZXF1aXJl bWVudCBsZXZlbHMgZm9yIGNvbXBsaWFudCBtZWNoYW5pc21zLgoKCjIuICBJbnRyb2R1Y3Rpb24K CiAgIFNlc3Npb24gcmVjb3JkaW5nIGlzIGEgY3JpdGljYWwgb3BlcmF0aW9uYWwgcmVxdWlyZW1l bnQgaW4gbWFueQogICBidXNpbmVzc2VzLCBlc3BlY2lhbGx5IHdoZXJlIHZvaWNlIGlzIHVzZWQg YXMgYSBtZWRpdW0gZm9yIGNvbW1lcmNlCiAgIGFuZCBjdXN0b21lciBzdXBwb3J0LiAgQSBwcmlt ZSBleGFtcGxlIHdoZXJlIHZvaWNlIGlzIHVzZWQgZm9yIHRyYWRlCiAgIGlzIHRoZSBmaW5hbmNp YWwgaW5kdXN0cnkuICBUaGUgY2FsbCByZWNvcmRpbmcgcmVxdWlyZW1lbnRzIGluIHRoaXMKICAg aW5kdXN0cnkgYXJlIHF1aXRlIHN0cmluZ2VudC4gIFRoZSByZWNvcmRlZCBjYWxscyBhcmUgdXNl ZCBmb3IKICAgZGlzcHV0ZSByZXNvbHV0aW9uIGFuZCBjb21wbGlhbmNlLiAgT3RoZXIgYnVzaW5l c3NlcyBzdWNoIGFzIGN1c3RvbWVyCiAgIHN1cHBvcnQgY2FsbCBjZW50ZXJzIHR5cGljYWxseSBl bXBsb3kgY2FsbCByZWNvcmRpbmcgZm9yIHF1YWxpdHkKICAgY29udHJvbCBvciBidXNpbmVzcyBh bmFseXRpY3MsIHdpdGggZGlmZmVyZW50IHJlcXVpcmVtZW50cy4KCiAgIERlcGVuZGluZyBvbiB0 aGUgY291bnRyeSBhbmQgaXRzIHJlZ3VsYXRvcnkgcmVxdWlyZW1lbnRzLCBmaW5hbmNpYWwKICAg dHJhZGluZyBmbG9vcnMgdHlwaWNhbGx5IG11c3QgcmVjb3JkIGFsbCBjYWxscy4gIEluIGNvbnRy YXN0LCBjYWxsCiAgIGNlbnRlcnMgdHlwaWNhbGx5IG9ubHkgcmVjb3JkIGEgc3Vic2V0IG9mIHRo ZSBjYWxscywgYW5kIGNhbGxzIG11c3QKICAgbm90IGZhaWwgcmVnYXJkbGVzcyBvZiB0aGUgYXZh aWxhYmlsaXR5IG9mIHRoZSByZWNvcmRpbmcgZGV2aWNlLgoKICAgUmVzcGVjdGluZyB0aGUgcHJp dmFjeSByaWdodHMgYW5kIHdpc2hlcyBvZiB1c2VycyBlbmdhZ2VkIGluIGEgY2FsbAogICBpcyBv ZiBwYXJhbW91bnQgaW1wb3J0YW5jZS4gIEluIG1hbnkganVyaXNkaWN0aW9ucyBwYXJ0aWNpcGFu dHMgaGF2ZQogICBhIHJpZ2h0IHRvIGtub3cgdGhhdCB0aGUgc2Vzc2lvbiBpcyBiZWluZyByZWNv cmRlZCBvciBtaWdodCBiZQogICByZWNvcmRlZCwgYW5kIGhhdmUgYSByaWdodCB0byBvcHQgb3V0 LCBlaXRoZXIgYnkgdGVybWluYXRpbmcgdGhlIGNhbGwKICAgb3IgYnkgZGVtYW5kaW5nIHRoYXQg dGhlIGNhbGwgbm90IGJlIHJlY29yZGVkLiAgVGhlcmVmb3JlIHRoaXMKICAgZG9jdW1lbnQgY29u dGFpbnMgcmVxdWlyZW1lbnRzIGZvciBiZWluZyBhYmxlIHRvIG5vdGlmeSB1c2VycyB0aGF0IGEK ICAgY2FsbCBpcyBiZWluZyByZWNvcmRlZCBhbmQgZm9yIHVzZXJzIHRvIGJlIGFibGUgdG8gcmVx dWVzdCB0aGF0IGEKICAgY2FsbCBub3QgYmUgcmVjb3JkZWQuICBVc2UgY2FzZXMgd2hlcmUgdXNl cnMgcGFydGljaXBhdGluZyBpbiBhIGNhbGwKICAgYXJlIG5vdCBpbmZvcm1lZCB0aGF0IHRoZSBj YWxsIGlzIG9yIG1pZ2h0IGJlIHJlY29yZGVkIGFyZSBvdXRzaWRlCiAgIHRoZSBzY29wZSBvZiB0 aGlzIGRvY3VtZW50LiAgSW4gcGFydGljdWxhciwgbGF3ZnVsIGludGVyY2VwdCBpcwogICBvdXRz aWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LgoKICAgRnVydGhlcm1vcmUsIHRoZSBzY2Fs ZSBhbmQgY29zdCBidXJkZW5zIHZhcnkgd2lkZWx5LCBpbiBhbGwgbWFya2V0cywKICAgd2hlcmUg dGhlIGRpZmZlcmVudCBuZWVkcyBmb3Igc29sdXRpb24gY2FwYWJpbGl0aWVzIHN1Y2ggYXMgbWVk aWEKICAgaW5qZWN0aW9uLCB0cmFuc2NvZGluZywgYW5kIHNlY3VyaXR5LXJlbGF0ZWQgbmVlZHMg ZG8gbm90IGNvbmZvcm0KICAgd2VsbCB0byBhIG9uZS1zaXplLWZpdHMtYWxsIG1vZGVsLiAgSWYg YSBzdGFuZGFyZGl6ZWQgc29sdXRpb24KICAgc3VwcG9ydHMgYWxsIG9mIHRoZSByZXF1aXJlbWVu dHMgZnJvbSBldmVyeSByZWNvcmRpbmcgbWFya2V0LCBidXQKICAgZG9pbmcgc28gd291bGQgYmUg ZXhwZW5zaXZlIGZvciBtYXJrZXRzIHdpdGggbGVzc2VyIG5lZWRzLCB0aGVuCiAgIHByb3ByaWV0 YXJ5IHNvbHV0aW9ucyBmb3IgdGhvc2UgbWFya2V0cyB3aWxsIGNvbnRpbnVlIHRvIHByb3BhZ2F0 ZS4KICAgQ2FyZSBtdXN0IGJlIHRha2VuLCB0aGVyZWZvcmUsIHRvIG1ha2UgYSBzdGFuZGFyZHMt YmFzZWQgc29sdXRpb24KICAgc3VwcG9ydCBvcHRpb25hbGl0eSBhbmQgZmxleGliaWxpdHkuCgog ICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyByZXF1aXJlbWVudHMgZm9yIHVzaW5nIFNJUCBbUkZD MzI2MV0gYmV0d2VlbgogICBhIFNlc3Npb24gUmVjb3JkaW5nIENsaWVudCBhbmQgYSBTZXNzaW9u IFJlY29yZGluZyBTZXJ2ZXIgdG8gY29udHJvbAoKCgpSZWhvciwgZXQgYWwuICAgICAgICAgICAg IEV4cGlyZXMgSnVseSAyOSwgMjAxMSAgICAgICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgUmVxdWlyZW1lbnRzIGZvciBTSVBSRUMgICAgICAgICAgICBKYW51 YXJ5IDIwMTEKCgogICB0aGUgcmVjb3JkaW5nIG9mIG1lZGlhIHRoYXQgaGFzIGJlZW4gdHJhbnNt aXR0ZWQgaW4gdGhlIGNvbnRleHQgb2YgYQogICBDb21tdW5pY2F0aW9uIFNlc3Npb24uICBBIENv bW11bmljYXRpb24gU2Vzc2lvbiBpcyB0aGUgImNhbGwiIGJldHdlZW4KICAgcGFydGljaXBhbnRz LiAgVGhlIFNlc3Npb24gUmVjb3JkaW5nIENsaWVudCBpcyB0aGUgc291cmNlIG9mIHRoZQogICBy ZWNvcmRlZCBtZWRpYS4gIFRoZSBTZXNzaW9uIFJlY29yZGluZyBTZXJ2ZXIgaXMgdGhlIHNpbmsg b2YgcmVjb3JkZWQKICAgbWVkaWEuICBJdCBzaG91bGQgYmUgbm90ZWQgdGhhdCB0aGUgcmVxdWly ZW1lbnRzIGZvciB0aGUgcHJvdG9jb2wKICAgYmV0d2VlbiBhIFNlc3Npb24gUmVjb3JkaW5nIFNl cnZlciBhbmQgU2Vzc2lvbiBSZWNvcmRpbmcgQ2xpZW50IGhhdmUKICAgdmVyeSBzaW1pbGFyIHJl cXVpcmVtZW50cyAoc3VjaCBhcyBjb2RlYyBhbmQgdHJhbnNwb3J0IG5lZ290aWF0aW9uLAogICBl bmNyeXB0aW9uIGtleSBpbnRlcmNoYW5nZSwgZmlyZXdhbGwgdHJhdmVyc2FsKSBhcyBjb21wYXJl ZCB0bwogICByZWd1bGFyIFNJUCBtZWRpYSBzZXNzaW9ucy4gIFRoZSBjaG9pY2Ugb2YgU0lQIGZv ciBzZXNzaW9uIHJlY29yZGluZwogICBwcm92aWRlcyByZXVzZSBvZiBhbiBleGlzdGluZyBwcm90 b2NvbC4KCiAgIFRoZSByZWNvcmRlZCBzZXNzaW9ucyBjYW4gYmUgYW55IFJUUCBtZWRpYSBzZXNz aW9ucyBpbmNsdWRpbmcgdm9pY2UsCiAgIERUTUYgKGFzIGRlZmluZWQgYnkgW1JGQzQ3MzNdKSwg dmlkZW8sIGFuZCB0ZXh0IChhcyBkZWZpbmVkIGJ5CiAgIFtSRkM0MTAzXSkuCgogICBBbiBhcmNo aXZlZCBzZXNzaW9uIHJlY29yZGluZyBpcyB0eXBpY2FsbHkgY29tcHJpc2VkIG9mIHRoZQogICBD b21tdW5pY2F0aW9uIFNlc3Npb24gbWVkaWEgY29udGVudCBhbmQgdGhlIENvbW11bmljYXRpb24g U2Vzc2lvbgogICBNZXRhZGF0YS4gIFRoZSBDb21tdW5pY2F0aW9uIFNlc3Npb24gTWV0YWRhdGEg YWxsb3dzIHJlY29yZGluZwogICBhcmNoaXZlcyB0byBiZSBzZWFyY2hlZCBhbmQgZmlsdGVyZWQg YXQgYSBsYXRlciB0aW1lIGFuZCBhbGxvd3MgYQogICBzZXNzaW9uIHRvIGJlIHBsYXllZCBiYWNr IGluIGEgbWVhbmluZ2Z1bCB3YXksIGUuZy4sIHdpdGggY29ycmVjdAogICBzeW5jaHJvbml6YXRp b24gYmV0d2VlbiB0aGUgbWVkaWEuICBUaGUgQ29tbXVuaWNhdGlvbiBTZXNzaW9uCiAgIE1ldGFk YXRhIG5lZWRzIHRvIGJlIGNvbnZleWVkIGZyb20gdGhlIFNlc3Npb24gUmVjb3JkaW5nIENsaWVu dCB0bwogICB0aGUgU2Vzc2lvbiBSZWNvcmRpbmcgU2VydmVyLgoKICAgVGhpcyBkb2N1bWVudCBv bmx5IGNvbnNpZGVycyBhY3RpdmUgcmVjb3JkaW5nLCB3aGVyZSB0aGUgU2Vzc2lvbgogICBSZWNv cmRpbmcgQ2xpZW50IHB1cnBvc2VmdWxseSBzdHJlYW1zIG1lZGlhIHRvIGEgU2Vzc2lvbiBSZWNv cmRpbmcKICAgU2VydmVyLiAgUGFzc2l2ZSByZWNvcmRpbmcsIHdoZXJlIGEgcmVjb3JkaW5nIGRl dmljZSBkZXRlY3RzIG1lZGlhCiAgIGRpcmVjdGx5IGZyb20gdGhlIG5ldHdvcmssIGlzIG91dHNp ZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuCgoKMy4gIERlZmluaXRpb25zCgogICBTZXNz aW9uIFJlY29yZGluZyBTZXJ2ZXIgKFNSUyk6IEEgU2Vzc2lvbiBSZWNvcmRpbmcgU2VydmVyIChT UlMpIGlzIGEKICAgU0lQIFVzZXIgQWdlbnQgKFVBKSB0aGF0IGlzIGEgc3BlY2lhbGl6ZWQgbWVk aWEgc2VydmVyIG9yIGNvbGxlY3RvcgogICB0aGF0IGFjdHMgYXMgdGhlIHNpbmsgb2YgdGhlIHJl Y29yZGVkIG1lZGlhLiAgQW4gU1JTIGlzIHR5cGljYWxseQogICBpbXBsZW1lbnRlZCBhcyBhIG11 bHRpLXBvcnQgZGV2aWNlIHRoYXQgaXMgY2FwYWJsZSBvZiByZWNlaXZpbmcgbWVkaWEKICAgZnJv bSBtdWx0aXBsZSBzb3VyY2VzIHNpbXVsdGFuZW91c2x5LiAgQW4gU1JTIGlzIHRoZSBzaW5rIG9m IHRoZQogICByZWNvcmRlZCBzZXNzaW9uIG1ldGFkYXRhLgoKICAgU2Vzc2lvbiBSZWNvcmRpbmcg Q2xpZW50IChTUkMpOiBBIFNlc3Npb24gUmVjb3JkaW5nIENsaWVudCAoU1JDKSBpcyBhCiAgIFNJ UCBVc2VyIEFnZW50IChVQSkgdGhhdCBhY3RzIGFzIHRoZSBzb3VyY2Ugb2YgdGhlIHJlY29yZGVk IG1lZGlhLAogICBzZW5kaW5nIGl0IHRvIHRoZSBTUlMuICBBbiBTUkMgaXMgYSBsb2dpY2FsIGZ1 bmN0aW9uLiAgSXRzCiAgIGNhcGFiaWxpdGllcyBtYXkgYmUgaW1wbGVtZW50ZWQgYWNyb3NzIG9u ZSBvciBtb3JlIHBoeXNpY2FsIGRldmljZXMuCiAgIEluIHByYWN0aWNlLCBhbiBTUkMgY291bGQg YmUgYSBwZXJzb25hbCBkZXZpY2UgKHN1Y2ggYXMgYSBTSVAgcGhvbmUpLAogICBhIFNJUCBNZWRp YSBHYXRld2F5IChNRyksIGEgU2Vzc2lvbiBCb3JkZXIgQ29udHJvbGxlciAoU0JDKSBvciBhIFNJ UAogICBNZWRpYSBTZXJ2ZXIgKE1TKSBpbnRlZ3JhdGVkIHdpdGggYW4gQXBwbGljYXRpb24gU2Vy dmVyIChBUykuICBUaGlzCiAgIHNwZWNpZmljYXRpb24gZGVmaW5lcyB0aGUgdGVybSBTUkMgc3Vj aCB0aGF0IGFsbCBzdWNoIFNJUCBlbnRpdGllcwogICBjYW4gYmUgZ2VuZXJpY2FsbHkgYWRkcmVz c2VkIHVuZGVyIG9uZSBkZWZpbml0aW9uLiAgVGhlIFNSQyBwcm92aWRlcwoKCgpSZWhvciwgZXQg YWwuICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAyOSwgMjAxMSAgICAgICAgICAgICAgICAgW1Bh Z2UgNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgUmVxdWlyZW1lbnRzIGZvciBTSVBSRUMg ICAgICAgICAgICBKYW51YXJ5IDIwMTEKCgogICBtZXRhZGF0YSB0byB0aGUgU1JTLgoKICAgQ29t bXVuaWNhdGlvbiBTZXNzaW9uIChDUyk6IEEgc2Vzc2lvbiBjcmVhdGVkIGJldHdlZW4gdHdvIG9y IG1vcmUgU0lQCiAgIFVzZXIgQWdlbnRzIChVQXMpIHRoYXQgaXMgdGhlIHN1YmplY3Qgb2YgcmVj b3JkaW5nLgoKICAgUmVjb3JkaW5nIFNlc3Npb24gKFJTKTogVGhlIFNJUCBzZXNzaW9uIGNyZWF0 ZWQgYmV0d2VlbiBhbiBTUkMgYW5kCiAgIFNSUyBmb3IgdGhlIHB1cnBvc2Ugb2YgcmVjb3JkaW5n IGEgQ29tbXVuaWNhdGlvbiBTZXNzaW9uLgoKICAgRmlndXJlIDEgcGljdG9yaWFsbHkgcmVwcmVz ZW50cyB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gYSBSZWNvcmRpbmcKICAgU2Vzc2lvbiBhbmQg Q29tbXVuaWNhdGlvbiBTZXNzaW9uLgoKCgogICAgICstLS0tLS0tLS0tLS0tKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tKwogICAgIHwgICAgICAgICAg ICAgfCAgICAgICAgQ29tbXVuaWNhdGlvbiBTZXNzaW9uICAgICAgICAgfCAgICAgICAgICAgfAog ICAgIHwgICAgIEEgICAgICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+ fCAgICAgQiAgICAgfAogICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgfAogICAgICstLS0tLS0tLS0tLS0tKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tKwogICAgIC4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LgogICAgIC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNlc3Npb24gICAgICAgICAgICAg ICAgICAgICAgICAgICAgLgogICAgIC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgUmVjb3Jk aW5nICAgICAgICAgICAgICAgICAgICAgICAgICAgLgogICAgIC4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgIENsaWVudCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLgogICAgIC4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8IFJlY29yZGluZwogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgU2Vzc2lvbgogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2CiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgIFNlc3Npb24gIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgIFJlY29yZGluZyB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgU2Vy dmVyICAgfAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLSsKCgog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMQoKICAgTWV0YWRhdGE6IElu Zm9ybWF0aW9uIHRoYXQgZGVzY3JpYmVzIHJlY29yZGVkIG1lZGlhIGFuZCB0aGUgQ1MgdG8KICAg d2hpY2ggdGhleSByZWxhdGUuCgogICBQYXVzZSBhbmQgUmVzdW1lIGR1cmluZyBhIENvbW11bmlj YXRpb24gU2Vzc2lvbjogUGF1c2U6IFRoZSBhY3Rpb24gb2YKICAgdGVtcG9yYXJpbHkgZGlzY29u dGludWluZyB0aGUgdHJhbnNtaXNzaW9uIGFuZCBjb2xsZWN0aW9uIG9mIFJTIG1lZGlhCiAgIFJl c3VtZTogVGhlIGFjdGlvbiBvZiByZWNvbW1lbmNpbmcgdGhlIHRyYW5zbWlzc2lvbiBhbmQgY29s bGVjdGlvbiBvZgogICBSUyBtZWRpYQoKCgoKCgoKUmVob3IsIGV0IGFsLiAgICAgICAgICAgICBF eHBpcmVzIEp1bHkgMjksIDIwMTEgICAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgIFJlcXVpcmVtZW50cyBmb3IgU0lQUkVDICAgICAgICAgICAgSmFudWFy eSAyMDExCgoKNC4gIFVzZSBDYXNlcwoKICAgVXNlIENhc2UgMTogRnVsbC10aW1lIFJlY29yZGlu ZzogT25lIFJlY29yZGluZyBTZXNzaW9uIGZvciBlYWNoCiAgIENvbW11bmljYXRpb24gU2Vzc2lv bi4KCiAgIEZvciBleGFtcGxlLCB0aGUgZGlhZ3JhbSBiZWxvdyBzaG93cyB0aGUgbGlmZWN5Y2xl IG9mIENvbW11bmljYXRpb24KICAgU2Vzc2lvbnMgKENTKSBhbmQgdGhlIHJlbGF0aW9uc2hpcCB0 byB0aGUgUmVjb3JkaW5nIFNlc3Npb25zIChSUykKCiAgIENTICB8LS0tIENTIDEgLS0tfCAgICAg IHwtLS0gQ1MgMiAtLS18ICAgICB8LS0tIENTIDMgLS0tfAoKICAgUlMgIHwtLS0gUlMgMSAtLS18 ICAgICAgfC0tLSBSUyAyIC0tLXwgICAgIHwtLS0gUlMgMyAtLS18CgogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBGaWd1cmUgMgoKICAgUmVjb3JkIGV2ZXJ5IENTIGZvciBzcGVjaWZp YyBleHRlbnNpb24vcGVyc29uLgoKICAgVGhlIG5lZWQgdG8gcmVjb3JkIGFsbCBjYWxscyBpcyB0 eXBpY2FsbHkgZHVlIHRvIGJ1c2luZXNzIHByb2Nlc3MKICAgcHVycG9zZXMgKHN1Y2ggYXMgdHJh bnNhY3Rpb24gY29uZmlybWF0aW9uIG9yIGRpc3B1dGUgcmVzb2x1dGlvbikgb3IKICAgdG8gZW5z dXJlIGNvbXBsaWFuY2Ugd2l0aCBnb3Zlcm5tZW50YWwgcmVndWxhdGlvbnMuICBBcHBsaWNhdGlv bnMKICAgaW5jbHVkZSBlbnRlcnByaXNlLCBjb250YWN0IGNlbnRlciwgYW5kIGZpbmFuY2lhbCB0 cmFkaW5nIGZsb29ycy4KCiAgIEFsc28gY29tbW9ubHkga25vd24gYXMgVG90YWwgUmVjb3JkaW5n LgoKICAgVXNlIENhc2UgMjogU2VsZWN0aXZlIFJlY29yZGluZzogU3RhcnQgYSBSZWNvcmRpbmcg U2Vzc2lvbiB3aGVuIGEKICAgQ29tbXVuaWNhdGlvbiBTZXNzaW9uIHRvIGJlIHJlY29yZGVkIGlz IGVzdGFibGlzaGVkLgoKICAgSW4gdGhpcyBleGFtcGxlLCBDb21tdW5pY2F0aW9uIFNlc3Npb25z IDEgYW5kIDMgYXJlIHJlY29yZGVkIGJ1dCBDUyAyCiAgIGlzIG5vdC4KCiAgIENTICB8LS0tIENT IDEgLS0tfCAgICAgIHwtLS0gQ1MgMiAtLS18ICAgICB8LS0tIENTIDMgLS0tfAoKICAgUlMgIHwt LS0gUlMgMS0tLS18ICAgICAgICAgICAgICAgICAgICAgICAgIHwtLS0gUlMgMiAtLS18CgogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMwoKICAgVXNlIENhc2UgMzogU3Rh cnQvU3RvcCBhIFJlY29yZGluZyBTZXNzaW9uIGR1cmluZyBhIENvbW11bmljYXRpb24KICAgU2Vz c2lvbi4KCiAgIFRoZSBSZWNvcmRpbmcgU2Vzc2lvbiBzdGFydHMgZHVyaW5nIGEgQ29tbXVuaWNh dGlvbiBTZXNzaW9uLCBlaXRoZXIKICAgbWFudWFsbHkgdmlhIGEgdXNlci1jb250cm9sbGVkIG1l Y2hhbmlzbSAoZS5nLiBidXR0b24gb24gdXNlcidzCiAgIHBob25lKSBvciBhdXRvbWF0aWNhbGx5 IHZpYSBhbiBhcHBsaWNhdGlvbiAoZS5nLiBhIENvbnRhY3QgQ2VudGVyCiAgIGN1c3RvbWVyIHNl cnZpY2UgYXBwbGljYXRpb24pIG9yIGJ1c2luZXNzIGV2ZW50LiAgQSBSZWNvcmRpbmcgU2Vzc2lv bgogICBlaXRoZXIgZW5kcyBkdXJpbmcgdGhlIENvbW11bmljYXRpb24gU2Vzc2lvbiwgb3Igd2hl biB0aGUKICAgQ29tbXVuaWNhdGlvbiBTZXNzaW9uIGVuZHMuICBPbmUgb3IgbW9yZSBSZWNvcmRp bmcgU2Vzc2lvbnMgbWF5CiAgIHJlY29yZCBlYWNoIENvbW11bmljYXRpb24gU2Vzc2lvbi4KCgoK CgoKUmVob3IsIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjksIDIwMTEgICAgICAg ICAgICAgICAgIFtQYWdlIDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIFJlcXVpcmVtZW50 cyBmb3IgU0lQUkVDICAgICAgICAgICAgSmFudWFyeSAyMDExCgoKICAgQ1MgIHwtLS0tLS0tLS0t LS0tIENvbW11bmljYXRpb24gU2Vzc2lvbiAtLS0tLS0tLS0tLXwKCiAgIFJTICAgICAgICAgICB8 LS0tLSBSUyAxIC0tLS18ICB8LS0tLSBSUyAyIC0tLS0tfAoKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgRmlndXJlIDQKCiAgIFVzZSBDYXNlIDQ6IFBlcnNpc3RlbnQgUmVjb3JkaW5n OiBBIHNpbmdsZSBSZWNvcmRpbmcgU2Vzc2lvbiBjYXB0dXJlcwogICBvbmUgb3IgbW9yZSBDb21t dW5pY2F0aW9uIFNlc3Npb25zLgoKCiAgICAgICAgICAgICB8LS0tIENTIDEgLS0tfCAgICAgIHwt LS0gQ1MgMiAtLS18ICAgICB8LS0tIENTIDMgLS0tfAoKICAgUlMgIHwtLS0tLS0tLS0tLS0tLS0t LS0tLS0tIFJlY29yZGluZyBTZXNzaW9uIC0tLS0tLS0tLS0tLS0tLS0tLS0tLXwKCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA1CgogICBBIFJlY29yZGluZyBTZXNzaW9u IHJlY29yZHMgY29udGludW91c2x5IHdpdGhvdXQgaW50ZXJydXB0aW9uLgogICBQZXJpb2RzIHdo ZW4gdGhlcmUgaXMgbm8gQ1MgaW4gcHJvZ3Jlc3MgbXVzdCBiZSByZXByb2R1Y2VkIHVwb24KICAg cGxheWJhY2sgKGUuZy4gYnkgcmVjb3JkaW5nIHNpbGVuY2UgZHVyaW5nIHN1Y2ggcGVyaW9kcyBv ciBieSBub3QKICAgcmVjb3JkaW5nIHN1Y2ggcGVyaW9kcyBidXQgbWFya2luZyB0aGVtIGJ5IG1l YW5zIG9mIG1ldGFkYXRhIGZvcgogICB1dGlsaXphdGlvbiBvbiBwbGF5YmFjaywgZXRjLikuICBB cHBsaWNhdGlvbnMgaW5jbHVkZSBmaW5hbmNpYWwKICAgdHJhZGluZyBkZXNrcyBhbmQgZW1lcmdl bmN5IChmaXJzdC1yZXNwb25kZXIpIHNlcnZpY2UgYnVyZWF1cy4gIFRoZQogICBsZW5ndGggb2Yg YSBQZXJzaXN0ZW50IFJlY29yZGluZyBTZXNzaW9uIGlzIGluZGVwZW5kZW50IGZyb20gdGhlCiAg IGxlbmd0aCBvZiB0aGUgYWN0dWFsIENvbW11bmljYXRpb24gU2Vzc2lvbnMuICBQZXJzaXN0ZW50 IFJlY29yZGluZwogICBTZXNzaW9ucyBhdm9pZCBpc3N1ZXMgc3VjaCBhcyBtZWRpYSBjbGlwcGlu ZyB0aGF0IGNhbiBvY2N1ciBkdWUgdG8KICAgZGVsYXlzIGluIFJlY29yZGluZyBTZXNzaW9uIGVz dGFibGlzaG1lbnQuCgogICBUaGUgY29ubmVjdGlvbiBhbmQgYXR0cmlidXRlcyBvZiBtZWRpYSBp biB0aGUgUmVjb3JkaW5nIFNlc3Npb24gYXJlCiAgIG5vdCBkeW5hbWljYWxseSBzaWduYWxlZCBm b3IgZWFjaCBDb21tdW5pY2F0aW9uIFNlc3Npb24gYmVmb3JlIGl0IGNhbgogICBiZSByZWNvcmRl ZDsgaG93ZXZlciwgY29kZWMgcmUtbmVnb3RpYXRpb24gaXMgcG9zc2libGUuCgogICBJbiBzb21l IGNhc2VzLCBtb3JlIHRoYW4gb25lIGNvbmN1cnJlbnQgQ29tbXVuaWNhdGlvbiBTZXNzaW9uIChv biBhCiAgIHNpbmdsZSBlbmQtdXNlciBhcHBhcmF0dXMsIGUuZy4gdHJhZGluZyBmbG9vciB0dXJy ZXQpIGlzIG1peGVkIGludG8KICAgb25lIFJlY29yZGluZyBTZXNzaW9uOgoKICAgICAgICAgICAg ICAgICB8LS0tLS0tLS0gQ1MgMSAtLS0tLS0tfAogICAgICAgICAgICAgICAgICAgIHwtLS0tLS0t LSBDUyAyIC0tLS0tLS18CiAgICAgICAgICAgICAgIHwtLS0tLS0tLSBDUyAzIC0tLS0tLS18Cgog ICBSUyAgfC0tLS0tLS0tLS0tIFJlY29yZGluZyBTZXNzaW9uIC0tLS0tLS0tLS0tLS0tfAoKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDYKCiAgIFVzZSBDYXNlIDU6IFJl YWwtdGltZSBSZWNvcmRpbmcgQ29udHJvbHMuCgogICBGb3IgYW4gYWN0aXZlIFJlY29yZGluZyBT ZXNzaW9uLCBwcml2YWN5IG9yIHNlY3VyaXR5IHJlYXNvbnMgbWF5CiAgIGRlbWFuZCBub3QgY2Fw dHVyaW5nIGEgc3BlY2lmaWMgcG9ydGlvbiBvZiBhIGNvbnZlcnNhdGlvbi4gIEFuCiAgIGV4YW1w bGUgaXMgZm9yIFBDSSAocGF5bWVudCBjYXJkIGluZHVzdHJ5KSBjb21wbGlhbmNlIHdoZXJlIGNy ZWRpdAoKCgpSZWhvciwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAyOSwgMjAxMSAg ICAgICAgICAgICAgICAgW1BhZ2UgOF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgUmVxdWly ZW1lbnRzIGZvciBTSVBSRUMgICAgICAgICAgICBKYW51YXJ5IDIwMTEKCgogICBjYXJkIGluZm8g bXVzdCBiZSBwcm90ZWN0ZWQuICBPbmUgc29sdXRpb24gaXMgdG8gbm90IHJlY29yZCBhIGNhbGxl cgogICBzcGVha2luZyB0aGVpciBjcmVkaXQgY2FyZCBpbmZvcm1hdGlvbi4KCiAgIEFuIGV4YW1w bGUgb2YgYSByZWFsLXRpbWUgY29udHJvbHMgaXMgUGF1c2UvUmVzdW1lLgoKICAgVXNlIENhc2Ug NjogSVZSIC8gVm9pY2UgUG9ydGFsIFJlY29yZGluZy4KCiAgIFNlbGYtc2VydmljZSBJbnRlcmFj dGl2ZSBWb2ljZSBSZXNwb25zZSBhcHBsaWNhdGlvbnMgbWF5IG5lZWQgdG8gYmUKICAgcmVjb3Jk ZWQgZm9yIGFwcGxpY2F0aW9uIHBlcmZvcm1hbmNlIHR1bmluZyBvciB0byBtZWV0IGNvbXBsaWFu Y2UKICAgcmVxdWlyZW1lbnRzLgoKICAgTWV0YWRhdGEgYWJvdXQgYW4gSVZSIHNlc3Npb24gcmVj b3JkaW5nIG11c3QgaW5jbHVkZSBzZXNzaW9uCiAgIGluZm9ybWF0aW9uIGFuZCBtYXkgaW5jbHVk ZSBhcHBsaWNhdGlvbiBjb250ZXh0IGluZm9ybWF0aW9uIChlLmcuCiAgIFZvaWNlWE1MIHNlc3Np b24gdmFyaWFibGVzLCBkaWFsb2cgbmFtZXMsIGV0Yy4pCgogICBVc2UgQ2FzZSA3OiBFbnRlcnBy aXNlIE1vYmlsaXR5IFJlY29yZGluZy4KCiAgIE1hbnkgYWdlbnRzIGFuZCBlbnRlcnByaXNlIHdv cmtlcnMgd2hvc2UgY2FsbHMgYXJlIHRvIGJlIHJlY29yZGVkIGFyZQogICBub3QgbG9jYXRlZCBv biBjb21wYW55IHByZW1pc2VzLgoKICAgRXhhbXBsZXM6CgogICBvIEhvbWUtYmFzZWQgYWdlbnRz IG9yIGVudGVycHJpc2Ugd29ya2Vycy4KCiAgIG8gTW9iaWxlIHBob25lcyBvZiBrbm93bGVkZ2Ug d29ya2VycyB3aGVuIHRoZXkgY29uZHVjdCB3b3JrIHJlbGF0ZWQKICAgKGFuZCBsZWdhbGx5IHJl cXVpcmVkIHJlY29yZGluZykgY2FsbHMuIGUuZy4gaW5zdXJhbmNlIGFnZW50cywKICAgYnJva2Vy cywgcGh5c2ljaWFucy4KCiAgIFVzZSBDYXNlIDg6IEdlb2dyYXBoaWNhbGx5IGRpc3RyaWJ1dGVk IG9yIGNlbnRyYWxpemVkIHJlY29yZGluZy4KCiAgIEVudGVycHJpc2VzIHN1Y2ggYXMgYmFua3Ms IGluc3VyYW5jZSBhZ2VuY2llcywgYW5kIHJldGFpbCBzdG9yZXMgbWF5CiAgIGhhdmUgbWFueSBs b2NhdGlvbnMsIHBvc3NpYmx5IHVwIHRvIHRob3VzYW5kcyBvZiBzbWFsbCBzaXRlcy4KICAgRnJl cXVlbnRseSBvbmx5IHBob25lcyBhbmQgbmV0d29yayBpbmZyYXN0cnVjdHVyZSBhcmUgaW5zdGFs bGVkIGluCiAgIGJyYW5jaGVzLCB3aXRob3V0IGxvY2FsIHJlY29yZGluZyBzZXJ2aWNlcy4gIElu IGNhc2VzIHdoZXJlIGNhbGxzCiAgIGluc2lkZSBvciBiZXR3ZWVuIGJyYW5jaGVzIG11c3QgYmUg cmVjb3JkZWQsIGEgY2VudHJhbGl6ZWQgcmVjb3JkaW5nCiAgIHN5c3RlbSBpbiBkYXRhIGNlbnRl cnMgdG9nZXRoZXIgd2l0aCB0ZWxlcGhvbnkgaW5mcmFzdHJ1Y3R1cmUgKGUuZy4KICAgUEJYKSBt ZSBkZXBsb3llZC4KCiAgIFVzZSBDYXNlIDk6IFJlY29yZCBjb21wbGV4IGNhbGwgc2NlbmFyaW9z LgoKICAgVGhlIGZvbGxvd2luZyBpcyBhbiBleGFtcGxlIG9mIGEgc2NlbmFyaW8gd2hlcmUgb25l IGNhbGwgdGhhdCBpcwogICByZWNvcmRlZCBtdXN0IGJlIGFzc29jaWF0ZWQgd2l0aCBhIHJlbGF0 ZWQgY2FsbCB0aGF0IGFsc28gbXVzdCBiZQogICByZWNvcmRlZC4KCiAgIG8gQSBDdXN0b21lciBp cyBpbiBhIGNvbnZlcnNhdGlvbiB3aXRoIGEgQ3VzdG9tZXIgU2VydmljZSBBZ2VudC4KCiAgIG8g QWdlbnQgcHV0cyBDdXN0b21lciBvbiBob2xkIGluIG9yZGVyIHRvIGNvbnN1bHQgd2l0aCBhIFN1 cGVydmlzb3IuCgoKCgpSZWhvciwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAyOSwg MjAxMSAgICAgICAgICAgICAgICAgW1BhZ2UgOV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg UmVxdWlyZW1lbnRzIGZvciBTSVBSRUMgICAgICAgICAgICBKYW51YXJ5IDIwMTEKCgogICBvIEFn ZW50IGVudGVycyBpbnRvIGEgY29udmVyc2F0aW9uIHdpdGggU3VwZXJ2aXNvci4KCiAgIG8gQWdl bnQgZGlzY29ubmVjdHMgZnJvbSBTdXBlcnZpc29yLCB0aGVuIHJlY29ubmVjdHMgd2l0aCBDdXN0 b21lci4KCiAgIG8gVGhlIFN1cGVydmlzb3IgY2FsbCBtdXN0IGJlIGFzc29jaWF0ZWQgd2l0aCB0 aGUgb3JpZ2luYWwgY3VzdG9tZXIKICAgY2FsbC4KCiAgIFVzZSBjYXNlIDEwOiBIaWdoIGF2YWls YWJpbGl0eSBhbmQgY29udGludW91cyByZWNvcmRpbmcuCgogICBTcGVjaWZpYyBkZXBsb3ltZW50 IHNjZW5hcmlvcyBwcmVzZW50IGRpZmZlcmVudCByZXF1aXJlbWVudHMgZm9yCiAgIHN5c3RlbSBh dmFpbGFiaWxpdHksIGVycm9yIGhhbmRsaW5nLCBldGMuIGluY2x1ZGluZzoKCiAgIG8gQW4gU1JT IG11c3QgYWx3YXlzIGJlIGF2YWlsYWJsZSBhdCBjYWxsIHNldHVwIHRpbWUuCgogICBvIE5vIGxv c3Mgb2YgbWVkaWEgcmVjb3JkaW5nLCBpbmNsdWRpbmcgZHVyaW5nIGZhaWx1cmUgb2YgYW4gU1JT LgoKICAgbyBUaGUgQ29tbXVuaWNhdGlvbiBTZXNzaW9uIG11c3QgYmUgdGVybWluYXRlZCAob3Ig c3VpdGFibGUKICAgbm90aWZpY2F0aW9uIGdpdmVuIHRvIHBhcnRpZXMpIGluIHRoZSBldmVudCBv ZiBhIHJlY29yZGluZyBmYWlsdXJlLgoKICAgVXNlIENhc2UgMTE6IFJlY29yZCBtdWx0aS1jaGFu bmVsLCBtdWx0aS1tZWRpYSBzZXNzaW9uLgoKICAgU29tZSBhcHBsaWNhdGlvbnMgcmVxdWlyZSB0 aGUgcmVjb3JkaW5nIG9mIG1vcmUgdGhhbiBvbmUgbWVkaWEKICAgc3RyZWFtLCBwb3NzaWJseSBv ZiBkaWZmZXJlbnQgdHlwZXMuICBNZWRpYSBhcmUgc3luY2hyb25pemVkLCBlaXRoZXIKICAgYXQg c3RvcmFnZSBvciBhdCBwbGF5YmFjay4KCiAgIFNwZWVjaCBhbmFseXRpY3MgdGVjaG5vbG9naWVz IChlLmcuIHdvcmQgc3BvdHRpbmcsIGVtb3Rpb24gZGV0ZWN0aW9uLAogICBzcGVha2VyIGlkZW50 aWZpY2F0aW9uKSBtYXkgcmVxdWlyZSBzcGVha2VyLXNlcGFyYXRlZCByZWNvcmRpbmdzIGZvcgog ICBvcHRpbXVtIHBlcmZvcm1hbmNlLgoKICAgTXVsdGktbW9kYWwgQ29udGFjdCBDZW50ZXJzIG1h eSBpbmNsdWRlIGF1ZGlvLCB2aWRlbywgSU0gb3Igb3RoZXIKICAgaW50ZXJhY3Rpb24gbW9kYWxp dGllcy4KCiAgIEluIHRyYWRpbmcgZmxvb3JzIGVudmlyb25tZW50cywgaW4gb3JkZXIgdG8gbWlu aW1pemUgc3RvcmFnZSBhbmQKICAgcmVjb3JkaW5nIHN5c3RlbSByZXNvdXJjZXMsIGl0IG1heSBi ZSBwcmVmZXJhYmxlIHRvIG1peCBtdWx0aXBsZQogICBjb25jdXJyZW50IGNhbGxzIChDb21tdW5p Y2F0aW9uIFNlc3Npb25zKSBvbiBkaWZmZXJlbnQgaGFuZHNldHMvCiAgIHNwZWFrZXJzIG9uIHRo ZSBzYW1lIHR1cnJldCBpbnRvIHNpbmdsZSByZWNvcmRpbmcgc2Vzc2lvbi4KCiAgIFVzZSBDYXNl IDEyOiBSZWFsLXRpbWUgbWVkaWEgcHJvY2Vzc2luZy4KCiAgIEl0IG11c3QgYmUgcG9zc2libGUg Zm9yIGFuIFNSUyB0byBzdXBwb3J0IHJlYWwtdGltZSBtZWRpYSBwcm9jZXNzaW5nLAogICBzdWNo IGFzIHNwZWVjaCBhbmFseXRpY3Mgb2YgdHJhZGluZyBmbG9vciBpbnRlcmFjdGlvbnMuICBSYWwt dGltZQogICBhbmFseXRpY3MgbWF5IGJlIGVtcGxveWVkIGZvciBhdXRvbWF0aWMgaW50ZXJ2ZW50 aW9uIChzdG9wcGluZwogICBpbnRlcmFjdGlvbiBvciBhbGVydGluZykgaWYgZm9yIGV4YW1wbGUs IGEgdHJhZGVyIGlzIG5vdCBmb2xsb3dpbmcKICAgcmVndWxhdGlvbnMuCgogICBTcGVha2VyIHNl cGFyYXRpb24gaXMgcmVxdWlyZWQgaW4gb3JkZXIgdG8gcmVsaWFibHkgZGV0ZWN0IHdobyBpcwog ICBzYXlpbmcgc3BlY2lmaWMgcGhyYXNlcy4KCgoKClJlaG9yLCBldCBhbC4gICAgICAgICAgICAg RXhwaXJlcyBKdWx5IDI5LCAyMDExICAgICAgICAgICAgICAgIFtQYWdlIDEwXQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgICBSZXF1aXJlbWVudHMgZm9yIFNJUFJFQyAgICAgICAgICAgIEphbnVh cnkgMjAxMQoKCjUuICBSZXF1aXJlbWVudHMKCiAgIFRoZSBmb2xsb3dpbmcgYXJlIHJlcXVpcmVt ZW50cyBmb3IgU0lQLWJhc2VkIE1lZGlhIFJlY29yZGluZzoKCiAgIG8gUkVRLTAwMSBUaGUgbWVj aGFuaXNtIE1VU1QgcHJvdmlkZSBhIG1lYW5zIGZvciAidXNpbmcgdGhlIFNJUAogICBwcm90b2Nv bCBmb3IiIGVzdGFibGlzaGluZywgbWFpbnRhaW5pbmcgYW5kIHRlcm1pbmF0aW5nIFJlY29yZGlu ZwogICBTZXNzaW9ucyBiZXR3ZWVuIGEgU2Vzc2lvbiBSZWNvcmRpbmcgQ2xpZW50IGFuZCBhIFNl c3Npb24gUmVjb3JkaW5nCiAgIFNlcnZlci4KCiAgIG8gUkVRLTAwMiBUaGUgbWVjaGFuaXNtIE1V U1Qgc3VwcG9ydCB0aGUgYWJpbGl0eSB0byByZWNvcmQgYWxsIENTcyBpbgogICB0aGVpciBlbnRp cmV0eS4KCiAgIG8gUkVRLTAwMyBUaGUgbWVjaGFuaXNtIE1VU1Qgc3VwcG9ydCB0aGUgYWJpbGl0 eSB0byByZWNvcmQgc2VsZWN0ZWQKICAgQ1NzIGluIHRoZWlyIGVudGlyZXR5LCBhY2NvcmRpbmcg dG8gcG9saWN5LgoKICAgbyBSRVEtMDA0IFRoZSBtZWNoYW5pc20gTVVTVCBzdXBwb3J0IHRoZSBh YmlsaXR5IHRvIHJlY29yZCBzZWxlY3RlZAogICBwYXJ0cyBvZiBzZWxlY3RlZCBDU3MuCgogICBv IFJFUS0wMDUgVGhlIG1lY2hhbmlzbSBNVVNUIHN1cHBvcnQgdGhlIGFiaWxpdHkgdG8gcmVjb3Jk IGEgQ1MKICAgd2l0aG91dCBsb3NzIG9mIG1lZGlhIChmb3IgZXhhbXBsZSwgY2xpcHBpbmcgbWVk aWEgYXQgdGhlIGJlZ2lubmluZwogICBvZiB0aGUgQ1MpIGR1ZSB0byBSUyByZWNvcmRpbmcgcHJl cGFyYXRpb24gYW5kIGFsc28sIHdpdGhvdXQKICAgaW1wYWN0aW5nIHRoZSBxdWFsaXR5IG9yIHRp bWluZyBvZiB0aGUgQ1MgKGZvciBleGFtcGxlLCBkZWxheWluZyB0aGUKICAgc3RhcnQgb2YgdGhl IENTIHdoaWxlIHByZXBhcmF0aW9uIGZvciByZWNvcmRpbmcgc2Vzc2lvbikuICBTZWUgVXNlCiAg IENhc2UgNCBpbiBTZWN0aW9uIDQgZm9yIG1vcmUgZGV0YWlscy4KCiAgIG8gUkVRLTAwNiBUaGUg bWVjaGFuaXNtIE1VU1Qgc3VwcG9ydCB0aGUgcmVjb3JkaW5nIG9mIElWUiBzZXNzaW9ucy4KCiAg IG8gUkVRLTAwNyBUaGUgbWVjaGFuaXNtIE1VU1Qgc3VwcG9ydCB0aGUgcmVjb3JkaW5nIG9mIFJU UCBtZWRpYSB0eXBlcwogICB2b2ljZSwgRFRNRiAoYXMgZGVmaW5lZCBieSBbUkZDNDczM10pLCB2 aWRlbywgYW5kIHRleHQgKGFzIGRlZmluZWQgYnkKICAgW1JGQzQxMDNdKS4KCiAgIG8gUkVRLTAw OCBUaGUgbWVjaGFuaXNtIE1VU1Qgc3VwcG9ydCB0aGUgYWJpbGl0eSBmb3IgYW4gU1JDIHRvCiAg IGRlbGl2ZXIgbWl4ZWQgYXVkaW8gc3RyZWFtcyBmcm9tIG11bHRpcGxlIENvbW11bmljYXRpb24g U2Vzc2lvbnMgdG8KICAgYW4gU1JTLgoKICAgTm90ZTogQSBtaXhlZCBhdWRpbyBzdHJlYW0gaXMg d2hlcmUgc2V2ZXJhbCBDb21tdW5pY2F0aW9uIFNlc3Npb25zCiAgIGFyZSBjYXJyaWVkIGluIGEg c2luZ2xlIFJlY29yZGluZyBTZXNzaW9uLiAgQSBtaXhlZCBtZWRpYSBzdHJlYW0gaXMKICAgdHlw aWNhbGx5IHByb2R1Y2VkIGJ5IGEgbWl4ZXIgZnVuY3Rpb24uICBUaGUgUlMgTUFZIGJlIGluZm9y bWVkIGFib3V0CiAgIHRoZSBjb21wb3NpdGlvbiBvZiB0aGUgbWl4ZWQgc3RyZWFtcyB0aHJvdWdo IHNlc3Npb24gbWV0YWRhdGEuCgogICBvIFJFUS0wMDk6IFRoZSBtZWNoYW5pc20gTVVTVCBzdXBw b3J0IHRoZSBhYmlsaXR5IGZvciBhbiBTUkMgdG8KICAgZGVsaXZlciBtaXhlZCBhdWRpbyBzdHJl YW1zIGZyb20gZGlmZmVyZW50IHBhcnRpZXMgb2YgYSBnaXZlbgogICBDb21tdW5pY2F0aW9uIFNl c3Npb24gdG8gYW4gU1JTLgoKICAgbyBSRVEtMDEwIFRoZSBtZWNoYW5pc20gTVVTVCBzdXBwb3J0 IHRoZSBhYmlsaXR5IHRvIGRlbGl2ZXIgdG8gdGhlCiAgIFNSUyBtdWx0aXBsZSBtZWRpYSBzdHJl YW1zIGZvciBhIGdpdmVuIENTLgoKICAgbyBSRVEtMDExIFRoZSBtZWNoYW5pc20gTVVTVCBzdXBw b3J0IHRoZSBhYmlsaXR5IHRvIHBhdXNlIGFuZCByZXN1bWUKCgoKUmVob3IsIGV0IGFsLiAgICAg ICAgICAgICBFeHBpcmVzIEp1bHkgMjksIDIwMTEgICAgICAgICAgICAgICAgW1BhZ2UgMTFdCgwK SW50ZXJuZXQtRHJhZnQgICAgICAgICAgIFJlcXVpcmVtZW50cyBmb3IgU0lQUkVDICAgICAgICAg ICAgSmFudWFyeSAyMDExCgoKICAgdGhlIHRyYW5zbWlzc2lvbiBhbmQgY29sbGVjdGlvbiBvZiBS UyBtZWRpYS4KCiAgIG8gUkVRLTAxMiBUaGUgbWVjaGFuaXNtIE1VU1QgcHJvdmlkZSB0aGUgU1JT IHdpdGggbWV0YWRhdGEgZGVzY3JpYmluZwogICBDU3MgdGhhdCBhcmUgYmVpbmcgcmVjb3JkZWQs IGluY2x1ZGluZyB0aGUgbWVkaWEgYmVpbmcgdXNlZCBhbmQgdGhlCiAgIGlkZW50aXRpZXMgb2Yg cGFydGllcyBpbnZvbHZlZC4KCiAgIG8gUkVRLTAxMyBUaGUgbWVjaGFuaXNtIE1VU1QgcHJvdmlk ZSB0aGUgU1JTIHdpdGggdGhlIG1lYW5zIHRvCiAgIGNvcnJlbGF0ZSBSUyBtZWRpYSB3aXRoIENT IHBhcnRpY2lwYW50IG1lZGlhLgoKICAgbyBSRVEtMDE0IE1ldGFkYXRhIGZvcm1hdCBtdXN0IGJl IGFnbm9zdGljIG9mIHRoZSB0cmFuc3BvcnQgcHJvdG9jb2wuCgogICBvIFJFUS0wMTU6IFRoZSBt ZWNoYW5pc20gTVVTVCBzdXBwb3J0IGEgbWVhbnMgdG8gY2FuY2VsIGFuZCBkaXNjYXJkCiAgIHRo ZSByZWNvcmRpbmcgYW5kIGFzc29jaWF0ZWQgbWV0YWRhdGEgZm9yIGEgQ1MuCgogICBvIFJFUS0w MTY6IFRoZSBtZWNoYW5pc20gTVVTVCBzdXBwb3J0IGEgbWVhbnMgdG8gY2FuY2VsIGFuZCBkaXNj YXJkCiAgIHRoZSByZWNvcmRpbmcgYnV0IG5vdCB0aGUgYXNzb2NpYXRlZCBtZXRhZGF0YSBmb3Ig YSBDUy4KCiAgIG8gUkVRLTAxNyBUaGUgbWVjaGFuaXNtIE1VU1Qgc3VwcG9ydCBhIG1lYW5zIGZv ciBhbiBhdXRob3JpemVkCiAgIHBhcnRpY2lwYW50IGludm9sdmVkIGluIGEgQ1MgdG8gcmVxdWVz dCwgcHJpb3IgdG8gdGhlIHN0YXJ0IG9mCiAgIHJlY29yZGluZywgdGhhdCB0aGUgQ1Mgbm90IGJl IHJlY29yZGVkCgogICBvIFJFUS0wMTggVGhlIG1lY2hhbmlzbSBNVVNUIHByb3ZpZGUgYSBtZWFu cyBvZiBpbmRpY2F0aW5nIHRvIHRoZQogICBwYXJ0aWNpcGFudHMgaW52b2x2ZWQgaW4gYSBDUyB0 aGF0IHRoZWlyIHNlc3Npb24gaXMgYmVpbmcgcmVjb3JkZWQuCgogICBFeGFtcGxlcyBpbmNsdWRl OiBpbmplY3QgdG9uZXMgaW50byB0aGUgQ1MgZnJvbSB0aGUgU1JDLCBwbGF5IGEKICAgbWVzc2Fn ZSBhdCB0aGUgYmVnaW5uaW5nIG9mIGEgc2Vzc2lvbiwgYSB2aXN1YWwgaW5kaWNhdG9yIG9uIGEK ICAgZGlzcGxheSwgZXRjLgoKICAgbyBSRVEtMDE5IFRoZSBtZWNoYW5pc20gTVVTVCBwcm92aWRl IGEgd2F5IGZvciBtZXRhZGF0YSB0byBiZQogICBjb252ZXllZCB0byB0aGUgU1JTIGluY3JlbWVu dGFsbHkgZHVyaW5nIHRoZSBDUy4KCiAgIG8gUkVRLTAyMCBUaGUgbWVjaGFuaXNtIE1VU1QgTk9U IHByZXZlbnQgaGlnaCBhdmFpbGFiaWxpdHkKICAgZGVwbG95bWVudHMuCgogICBvIFJFUS0wMjIg VGhlIG1lY2hhbmlzbSBNVVNUIHByb3ZpZGUgdGhlIFNSUyB0aGUgc3RhcnRpbmcgd2FsbCBjbG9j awogICB0aW1lIGZvciBlYWNoIFJTIG1lZGlhIHN0cmVhbSBjb3JyZXNwb25kaW5nIHRvIHRoZSBD UyBwYXJ0aWNpcGFudAogICBtZWRpYS4KCiAgIG8gUkVRLTAyMyBUaGUgbWVjaGFuaXNtIE1VU1Qg cHJvdmlkZSB0aGUgU1JTIHRoZSB3YWxsIGNsb2NrIHRpbWUgd2hlbgogICB0aGUgUmVjb3JkaW5n IFNlc3Npb24gaXMgcGF1c2VkIGFuZCByZXN1bWVkLgoKICAgbyBSRVEtMDI0IFRoZSBtZWNoYW5p c20gTVVTVCBzdXBwb3J0IGZ1bmN0aW9uYWxpdHkgc3VjaCB0aGF0IGlmIHRoZQogICBDUyBpcyBl bmNyeXB0ZWQsIHRoZSBSUyBtYXkgdXNlIHRoZSBzYW1lIG9yIGRpZmZlcmVudCBlbmNyeXB0aW9u CiAgIGtleXMuCgogICBvIFJFUS0wMjUgVGhlIG1lY2hhbmlzbSBNVVNUIHByb3ZpZGUgbWVhbnMg Zm9yIGFuIFNSUyB0byBhdXRoZW50aWNhdGUKICAgdGhlIFNSQyBvbiBSUyBpbml0aWF0aW9uLgoK CgoKUmVob3IsIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjksIDIwMTEgICAgICAg ICAgICAgICAgW1BhZ2UgMTJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIFJlcXVpcmVtZW50 cyBmb3IgU0lQUkVDICAgICAgICAgICAgSmFudWFyeSAyMDExCgoKICAgbyBSRVEtMDI2IFRoZSBt ZWNoYW5pc20gTVVTVCBwcm92aWRlIG1lYW5zIGZvciBhbiBTUkMgdG8gYXV0aGVudGljYXRlCiAg IHRoZSBTUlMgb24gUlMgaW5pdGlhdGlvbi4KCiAgIG8gUkVRLTAyNyBUaGUgbWVjaGFuaXNtIE1V U1QgZW5zdXJlIHRoYXQgdGhlIGludGVncml0eSBvZiB0aGUKICAgbWV0YWRhdGEgc2VudCBmcm9t IFNSQyB0byBTUlMgaXMgYW4gYWNjdXJhdGUgcmVwcmVzZW50YXRpb24gb2YgdGhlCiAgIG9yaWdp bmFsIENTIG1ldGFkYXRhLgoKICAgbyBSRVEtMDI4IFRoZSBtZWNoYW5pc20gTVVTVCBlbnN1cmUg dGhhdCB0aGUgaW50ZWdyaXR5IG9mIHRoZSBtZWRpYQogICBzZW50IGZyb20gU1JDIHRvIFNSUyBp cyBhbiBhY2N1cmF0ZSByZXByZXNlbnRhdGlvbiBvZiB0aGUgb3JpZ2luYWwgQ1MKICAgbWVkaWEu CgogICBvIFJFUS0wMjkgVGhlIG1lY2hhbmlzbSBNVVNUIGVuc3VyZSB0aGUgY29uZmlkZW50aWFs aXR5IG9mIHRoZQogICBNZXRhZGF0YSBzZW50IGZyb20gU1JDIHRvIFNSUy4KCiAgIG8gUkVRLTAz MCBUaGUgbWVjaGFuaXNtIE1VU1QgcHJvdmlkZSBhIG1lYW5zIHRvIHN1cHBvcnQgUlMKICAgY29u ZmlkZW50aWFsaXR5LgoKICAgbyBSRVEtMDAweHh4IFRoZSBtZWNoYW5pc20gTVVTVCBzdXBwb3J0 IHRoZSBhYmlsaXR5IHRvIGRlbGl2ZXIgdG8gdGhlCiAgIFNSUyBtdWx0aXBsZSBtZWRpYSBzdHJl YW1zIG9mIHRoZSBzYW1lIG1lZGlhIHR5cGUgKGUuZy4gYXVkaW8sCiAgIHZpZGVvKS4gIEZvciBl eGFtcGxlIGluIHRoZSBjYXNlIG9mIGRlbGl2ZXJpbmcgdW5taXhlZCBhdWRpbyBmb3IgZWFjaAog ICBwYXJ0aWNpcGFudCBpbiB0aGUgQ1MuCgoKNi4gIFByaXZhY3kgQ29uc2lkZXJhdGlvbnMKCiAg IFJlc3BlY3RpbmcgdGhlIHByaXZhY3kgcmlnaHRzIGFuZCB3aXNoZXMgb2YgdXNlcnMgZW5nYWdl ZCBpbiBhIGNhbGwKICAgaXMgb2YgcGFyYW1vdW50IGltcG9ydGFuY2UuICBJbiBtYW55IGp1cmlz ZGljdGlvbnMgcGFydGljaXBhbnRzIGhhdmUKICAgYSByaWdodCB0byBrbm93IHRoYXQgdGhlIHNl c3Npb24gaXMgYmVpbmcgcmVjb3JkZWQgb3IgbWlnaHQgYmUKICAgcmVjb3JkZWQsIGFuZCBoYXZl IGEgcmlnaHQgdG8gb3B0IG91dCwgZWl0aGVyIGJ5IHRlcm1pbmF0aW5nIHRoZSBjYWxsCiAgIG9y IGJ5IGRlbWFuZGluZyB0aGF0IHRoZSBjYWxsIG5vdCBiZSByZWNvcmRlZC4gIFRoZXJlZm9yZSB0 aGlzCiAgIGRvY3VtZW50IGNvbnRhaW5zIHJlcXVpcmVtZW50cyBmb3IgYmVpbmcgYWJsZSB0byBu b3RpZnkgdXNlcnMgdGhhdCBhCiAgIGNhbGwgaXMgYmVpbmcgcmVjb3JkZWQgYW5kIGZvciB1c2Vy cyB0byBiZSBhYmxlIHRvIHJlcXVlc3QgdGhhdCBhCiAgIGNhbGwgbm90IGJlIHJlY29yZGVkLiAg VXNlIGNhc2VzIHdoZXJlIHVzZXJzIHBhcnRpY2lwYXRpbmcgaW4gYSBjYWxsCiAgIGFyZSBub3Qg aW5mb3JtZWQgdGhhdCB0aGUgY2FsbCBpcyBvciBtaWdodCBiZSByZWNvcmRlZCBhcmUgb3V0c2lk ZQogICB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gIEluIHBhcnRpY3VsYXIsIGxhd2Z1bCBp bnRlcmNlcHQgaXMKICAgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4KCiAgIFJl cXVpcmVtZW50cyBmb3IgcGFydGljaXBhbnQgbm90aWZpY2F0aW9uIG9mIHJlY29yZGluZyB2YXJp ZXMgd2lkZWx5CiAgIGJ5IGp1cmlzZGljdGlvbi4gIEluIGEgZ2l2ZW4gZGVwbG95bWVudCwgbm90 IGFsbCB1c2VycyB3aWxsIGJlCiAgIGF1dGhvcml6ZWQgdG8gc3RvcCB0aGUgcmVjb3JkaW5nIG9m IGEgQ1MgKGFsdGhvdWdoIGFueSB1c2VyIGNhbgogICB0ZXJtaW5hdGUgYSBDUykuICBUeXBpY2Fs bHkgdXNlcnMgd2l0aGluIHRoZSBkb21haW4gdGhhdCBpcyBjYXJyeWluZwogICBvdXQgdGhlIHJl Y29yZGluZyB3aWxsIGJlIHN1YmplY3QgdG8gcG9saWNpZXMgb2YgdGhhdCBkb21haW4KICAgY29u Y2VybmluZyB3aGV0aGVyIENTcyBhcmUgcmVjb3JkZWQuICBGb3IgZXhhbXBsZSwgaW4gYSBjYWxs IGNlbnRyZSwKICAgYWdlbnRzIHdpbGwgYmUgc3ViamVjdCB0byBwb2xpY2llcyBvZiB0aGUgY2Fs bCBjZW50cmUgYW5kIG1heSBvciBtYXkKICAgbm90IGhhdmUgdGhlIHJpZ2h0IHRvIHByZXZlbnQg dGhlIHJlY29yZGluZyBvZiBhIENTIG9yIHBhcnQgb2YgYSBDUy4KICAgVXNlcnMgY2FsbGluZyBp bnRvIHRoZSBjYWxsIGNlbnRyZSwgb24gdGhlIG90aGVyIGhhbmQsIHdpbGwgdHlwaWNhbGx5CiAg IGhhdmUgdG8gYXNrIHRoZSBhZ2VudCBub3QgdG8gcmVjb3JkIHRoZSBDUy4gIElmIHRoZSBhZ2Vu dCBpcyB1bmFibGUKICAgdG8gcHJldmVudCByZWNvcmRpbmcsIG9yIGlmIHRoZSBjYWxsZXIgZG9l cyBub3QgdHJ1c3QgdGhlIGFnZW50LCB0aGUKCgoKUmVob3IsIGV0IGFsLiAgICAgICAgICAgICBF eHBpcmVzIEp1bHkgMjksIDIwMTEgICAgICAgICAgICAgICAgW1BhZ2UgMTNdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgIFJlcXVpcmVtZW50cyBmb3IgU0lQUkVDICAgICAgICAgICAgSmFudWFy eSAyMDExCgoKICAgb25seSBvcHRpb24gZ2VuZXJhbGx5IGlzIHRvIHRlcm1pbmF0ZSB0aGUgQ1Mu CgogICBQcml2YWN5IGNvbnNpZGVyYXRpb25zIGFsc28gZXh0ZW5kIHRvIHdoYXQgaGFwcGVucyB0 byBhIHJlY29yZGluZwogICBvbmNlIGl0IGhhcyBiZWVuIGNyZWF0ZWQuICBUeXBpY2FsIGlzc3Vl cyBhcmUgd2hvIGNhbiBhY2Nlc3MgdGhlCiAgIHJlY29yZGluZyAoZS5nLiwgcmVjZWl2ZSBhIGNv cHkgb2YgdGhlIHJlY29yZGluZywgdmlldyB0aGUgbWV0YWRhdGEsCiAgIHBsYXkgYmFjayB0aGUg bWVkaWEsIGV0Yy4pLCBmb3Igd2hhdCBwdXJwb3NlIHRoZSByZWNvcmRpbmcgY2FuIGJlCiAgIHVz ZWQgKGUuZy4sIGZvciBub24tcmVwdWRpYXRpb24sIGZvciB0cmFpbmluZyBwdXJwb3NlcywgZm9y IHF1YWxpdHkKICAgY29udHJvbCBwdXJwb3NlcywgZXRjLikgYW5kIGZvciBob3cgbG9uZyB0aGUg cmVjb3JkaW5nIGlzIHRvIGJlCiAgIHJldGFpbmVkIGJlZm9yZSBkZWxldGlvbi4gIFRoZXNlIGFy ZSB0eXBpY2FsbHkgcG9saWNpZXMgb2YgdGhlIGRvbWFpbgogICB0aGF0IG1ha2VzIHRoZSByZWNv cmRpbmcsIHJhdGhlciB0aGFuIHBvbGljaWVzIG9mIGluZGl2aWR1YWwgdXNlcnMKICAgaW52b2x2 ZWQgaW4gYSByZWNvcmRlZCBDUywgd2hldGhlciB0aG9zZSB1c2VycyBiZSBpbiB0aGUgc2FtZSBk b21haW4KICAgb3IgaW4gYSBkaWZmZXJlbnQgZG9tYWluLiAgVGFraW5nIHRoZSBjYWxsIGNlbnRy ZSBleGFtcGxlIGFnYWluLAogICBhZ2VudHMgbWlnaHQgYmUgbWFkZSBhd2FyZSBvZiBjYWxsIGNl bnRyZSBwb2xpY3kgcmVnYXJkaW5nIHJldGVudGlvbgogICBhbmQgdXNlIG9mIHJlY29yZGluZ3Mg YXMgcGFydCBvZiB0aGVpciBlbXBsb3ltZW50IGNvbnRyYWN0LCBhbmQKICAgY2FsbGVycyBmcm9t IG91dHNpZGUgdGhlIGNhbGwgY2VudHJlIG1pZ2h0IGJlIGdpdmVuIHNvbWUgaW5mb3JtYXRpb24K ICAgYWJvdXQgcG9saWN5IHdoZW4gbm90aWZpZWQgdGhhdCBhIENTIHdpbGwgYmUgcmVjb3JkZWQg KGUuZy4sIHRocm91Z2gKICAgYW4gYW5ub3VuY2VtZW50IHRoYXQgc2F5cyB0aGF0IGNhbGxzIG1h eSBiZSByZWNvcmRlZCBmb3IgcXVhbGl0eQogICBwdXJwb3NlcykuCgogICBUaGlzIGRvY3VtZW50 IGRvZXMgbm90IHNwZWNpZnkgYW55IHJlcXVpcmVtZW50cyBmb3IgYSB1c2VyIGVuZ2FnZWQgaW4K ICAgYSBDUyB0byBiZSBhYmxlIHRvIGRpY3RhdGUgcG9saWN5IGZvciB3aGF0IGhhcHBlbnMgdG8g YSByZWNvcmRpbmcsIG9yCiAgIGZvciBzdWNoIGluZm9ybWF0aW9uIHRvIGJlIGNvbnZleWVkIGZy b20gYW4gU1JDIHRvIGFuIFNSUy4gIEl0IGlzCiAgIGFzc3VtZWQgdGhhdCB0aGUgU1JTIGhhcyBh Y2Nlc3MgdG8gcG9saWN5IGFwcGxpY2FibGUgdG8gaXRzCiAgIGVudmlyb25tZW50IGFuZCBjYW4g ZW5zdXJlIHRoYXQgcmVjb3JkaW5ncyBhcmUgc3RvcmVkIGFuZCB1c2VkIGluCiAgIGFjY29yZGFu Y2Ugd2l0aCB0aGF0IHBvbGljeS4KCgo3LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIFNl c3Npb24gcmVjb3JkaW5nIGhhcyBzdWJzdGFudGlhbCBzZWN1cml0eSBpbXBsaWNhdGlvbnMsIGZv ciB0aGUgU0lQCiAgIFVBJ3MgYmVpbmcgcmVjb3JkZWQsIHRoZSBTUkMsIGFuZCB0aGUgU1JTLgoK ICAgRm9yIHRoZSBTSVAgVUEncyBpbnZvbHZlZCBpbiB0aGUgQ29tbXVuaWNhdGlvbiBTZXNzaW9u LCB0aGUKICAgcmVxdWlyZW1lbnRzIGluIHRoaXMgZHJhZnQgZW5hYmxlIHRoZSBVQSB0byBpZGVu dGlmeSB0aGF0IGEKICAgQ29tbXVuaWNhdGlvbiBTZXNzaW9uIGlzIGJlaW5nIHJlY29yZGVkIGFu ZCBmb3IgdGhlIFVBIHRvIHJlcXVlc3QKICAgdGhhdCBhIGdpdmVuIENvbW11bmljYXRpb24gU2Vz c2lvbiBpcyBub3Qgc3ViamVjdCB0byByZWNvcmRpbmcuCgogICBTaW5jZSBodW1hbnMgZG9uJ3Qg dHlwaWNhbGx5IGxvb2sgYXQgb3Iga25vdyBhYm91dCBwcm90b2NvbCBzaWduYWxpbmcKICAgc3Vj aCBhcyBTSVAsIGFuZCBpbmRlZWQgdGhlIFNJUCBzZXNzaW9uIG1pZ2h0IGhhdmUgb3JpZ2luYXRl ZCB0aHJvdWdoCiAgIGEgUFNUTiBHYXRld2F5IHdpdGhvdXQgYW55IGFiaWxpdHkgdG8gcGFzcyBv biBpbi1zaWduYWxpbmcKICAgaW5kaWNhdGlvbnMgb2YgcmVjb3JkaW5nLCB1c2VycyBjYW4gYmUg bm90aWZpZWQgb2YgcmVjb3JkaW5nIGluIHRoZQogICBtZWRpYSBpdHNlbGYgdGhyb3VnaCB2b2lj ZSBhbm5vdW5jZW1lbnRzLCBhIHZpc3VhbCBpbmRpY2F0b3Igb24gdGhlCiAgIGVuZHBvaW50LCBv ciBvdGhlciBtZWFucy4KCiAgIFdpdGggcmVnYXJkcyB0byBzZWN1cml0eSBpbXBsaWNhdGlvbnMg b2YgdGhlIHByb3RvY29sKHMpLCBjbGVhcmx5CiAgIHRoZXJlIGlzIGEgbmVlZCBmb3IgYXV0aGVu dGljYXRpb24sIGF1dGhvcml6YXRpb24sIGVhdmVzZHJvcHBpbmcKICAgcHJvdGVjdGlvbiwgYW5k IG5vbi1yZXB1ZGlhdGlvbiBmb3IgdGhlIHNvbHV0aW9uLiAgVGhlIFNSQyBuZWVkcyB0bwogICBr bm93IHRoZSBTUlMgaXQgaXMgY29tbXVuaWNhdGluZyB3aXRoIGlzIGxlZ2l0aW1hdGUsIGFuZCB2 aWNlLXZlcnNhLAoKCgpSZWhvciwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAyOSwg MjAxMSAgICAgICAgICAgICAgICBbUGFnZSAxNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg UmVxdWlyZW1lbnRzIGZvciBTSVBSRUMgICAgICAgICAgICBKYW51YXJ5IDIwMTEKCgogICBldmVu IGlmIHRoZXkgYXJlIGluIGRpZmZlcmVudCBkb21haW5zLiAgQm90aCB0aGUgc2lnbmFsaW5nIGFu ZCBtZWRpYQogICBmb3IgdGhlIFJlY29yZGluZyBTZXNzaW9uIG5lZWQgdGhlIGFiaWxpdHkgdG8g YmUgYXV0aGVudGljYXRlZCBhbmQKICAgcHJvdGVjdGVkIGZyb20gZWF2ZXNkcm9wcGluZyBhbmQg bm9uLXJlcHVkaWF0aW9uLiAgUmVxdWlyZW1lbnRzIGFyZQogICBkZXRhaWxlZCBpbiB0aGUgcmVx dWlyZW1lbnRzIHNlY3Rpb24uCgoKOC4gIElBTkEgQ29uc2lkZXJhdGlvbnMKCiAgIFRoaXMgZG9j dW1lbnQgaGFzIG5vIElBTkEgYWN0aW9ucy4KCgo5LiAgQWNrbm93bGVkZ2VtZW50cwoKICAgVGhh bmtzIHRvIERhbiBXaW5nLCBBbGFuIEpvaG5zb24sIFZpamF5IEd1cmJhbmksIEN1bGxlbiBKZW5u aW5ncywKICAgSGFkcmllbCBLYXBsYW4sIEhlbnJ5IEx1bSwgRGF2ZSBTbWl0aCwgTWFydGluIFBh bG1lciwgQWxpc3NhIENvb3BlciwKICAgRGVlcGFuc2h1IEdhdXRhbSwgUGF1bCBLeXppdmF0LCBQ YXJ0aGFzYXJhdGhpIFIsIGFuZCBSYW0gTW9oYW4gUiBmb3IKICAgdGhlaXIgc2lnbmlmaWNhbnQg Y29udHJpYnV0aW9ucyBhbmQgYXNzaXN0YW5jZSB3aXRoIHRoaXMgZG9jdW1lbnQgYW5kCiAgIFdv cmtpbmcgR3JvdXAsIGFuZCB0byBhbGwgdGhlIG1lbWJlcnMgb2YgdGhlIERJU1BBVENIIFdHIGFu ZCBTSVBSRUMKICAgV0cgbWFpbGluZyBsaXN0cyBmb3IgcHJvdmlkaW5nIHZhbHVhYmxlIGlucHV0 IHRvIHRoaXMgd29yay4KCgoxMC4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbUkZDMjExOV0g IEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQogICAg ICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5 OTcuCgogICBbUkZDMjgwNF0gIElBQiBhbmQgSUVTRywgIklFVEYgUG9saWN5IG9uIFdpcmV0YXBw aW5nIiwgUkZDIDI4MDQsCiAgICAgICAgICAgICAgTWF5IDIwMDAuCgogICBbUkZDMzI2MV0gIFJv c2VuYmVyZywgSi4sIFNjaHVsenJpbm5lLCBILiwgQ2FtYXJpbGxvLCBHLiwgSm9obnN0b24sCiAg ICAgICAgICAgICAgQS4sIFBldGVyc29uLCBKLiwgU3BhcmtzLCBSLiwgSGFuZGxleSwgTS4sIGFu ZCBFLgogICAgICAgICAgICAgIFNjaG9vbGVyLCAiU0lQOiBTZXNzaW9uIEluaXRpYXRpb24gUHJv dG9jb2wiLCBSRkMgMzI2MSwKICAgICAgICAgICAgICBKdW5lIDIwMDIuCgoKQXV0aG9ycycgQWRk cmVzc2VzCgogICBLZW4gUmVob3IgKGVkaXRvcikKICAgQ2lzY28gU3lzdGVtcwogICAxNzAgV2Vz dCBUYXNtYW4gRHIuCiAgIE1haWwgU3RvcCBTSkMzMC8yLwogICBTYW4gSm9zZSwgQ0EgIDk1MTM0 CiAgIFVTQQoKICAgRW1haWw6IGtyZWhvckBjaXNjby5jb20KCgoKCgoKUmVob3IsIGV0IGFsLiAg ICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjksIDIwMTEgICAgICAgICAgICAgICAgW1BhZ2UgMTVd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIFJlcXVpcmVtZW50cyBmb3IgU0lQUkVDICAgICAg ICAgICAgSmFudWFyeSAyMDExCgoKICAgTGVvbiBQb3J0bWFuIChlZGl0b3IpCiAgIE5JQ0UgU3lz dGVtcwogICA4IEhhcG5pbmEKICAgUmEnYW5hbmEgIDQzMDE3CiAgIElzcmFlbAoKICAgRW1haWw6 IGxlb24ucG9ydG1hbkBuaWNlLmNvbQoKCiAgIEFuZHJldyBIdXR0b24KICAgU2llbWVucyBFbnRl cnByaXNlIENvbW11bmljYXRpb25zCgogICBFbWFpbDogYW5kcmV3Lmh1dHRvbkBzaWVtZW5zLWVu dGVycHJpc2UuY29tCiAgIFVSSTogICBodHRwOi8vd3d3LnNpZW1lbnMtZW50ZXJwcmlzZS5jb20K CgogICBSYWpuaXNoIEphaW4KICAgSVBDIFN5c3RlbXMKICAgNzc3IENvbW1lcmNlIERyaXZlCiAg IEZhaXJmaWVsZCwgQ1QgIDA2ODI1CiAgIFVTQQoKICAgRW1haWw6IHJham5pc2guamFpbkBpcGMu Y29tCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpSZWhvciwgZXQgYWwuICAgICAgICAgICAg IEV4cGlyZXMgSnVseSAyOSwgMjAxMSAgICAgICAgICAgICAgICBbUGFnZSAxNl0KDAoK ------_=_NextPart_001_01CBBC6A.FB1B5063-- From andrew.hutton@siemens-enterprise.com Tue Jan 25 01:04:50 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 094FA3A6B76 for ; Tue, 25 Jan 2011 01:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QedfObEOnO7w for ; Tue, 25 Jan 2011 01:04:48 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 270153A69B1 for ; Tue, 25 Jan 2011 01:04:48 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3129167; Tue, 25 Jan 2011 10:07:42 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 1278E23F0278; Tue, 25 Jan 2011 10:07:42 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 25 Jan 2011 10:07:42 +0100 From: "Hutton, Andrew" To: "Ken Rehor (krehor)" , "Elwell, John" , "siprec@ietf.org" Date: Tue, 25 Jan 2011 10:07:41 +0100 Thread-Topic: [siprec] WGLC comments on siprec-req-06 Thread-Index: Acu2YyIsRf9CmsUSTiKw4g9xxHZSWAF/sFmwAANTEEA= Message-ID: <101C6067BEC68246B0C3F6843BCCC1E30ABAB246AC@MCHP058A.global-ad.net> References: <7744FE52C78D944587F03773EB4514610947F3F2@xmb-sjc-22e.amer.cisco.com> In-Reply-To: <7744FE52C78D944587F03773EB4514610947F3F2@xmb-sjc-22e.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] WGLC comments on siprec-req-06 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 09:04:50 -0000 Looks good to me and ready to go. Regards Andy=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Ken Rehor (krehor) > Sent: 25 January 2011 08:37 > To: Elwell, John; siprec@ietf.org > Subject: Re: [siprec] WGLC comments on siprec-req-06 >=20 > Draft of -07 attached, including changes noted below and in=20 > Leon's email > of 24 Jan. >=20 > Ken >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of > > Elwell, John > > Sent: Monday, January 17, 2011 8:25 AM > > To: siprec@ietf.org > > Subject: [siprec] WGLC comments on siprec-req-06 > >=20 > > My WGLC comments (as individual). > >=20 > > I think the document is almost ready to go, but needs the following > minor > > points and nits fixing. > >=20 > > Minor: > > 1. Abstract: > > "This document specifies requirements for > > extensions to SIP that will manage delivery of RTP media from an > end- > > point that originates media (or that has access to it) to a > recording > > device." > > The words "end-point" and "originates" are not really suitable where > the > > SRC is at a B2BUA. I would suggest rewording as: > > "This document specifies requirements for extensions to SIP=20 > that will > > manage delivery of RTP media to a recording device." >=20 > [ ] done. > =20 > > 2. Section 3: > > "An SRS is a logical > > function that typically archives media for extended durations of > time > > and provides interfaces for search and retrieval of the archived > > media." > > I don't think the SRS provides such interfaces. Such=20 > interfaces would > be > > available, but I don't think they should be considered part of the > SRS. > > Also I don't think the word "typically" is necessary. I=20 > would suggest > a > > reword as follows: > > "An SRS is a logical function that archives media for extended > periods. > > Other functions can provide interfaces for searching and retrieving > > archived media." >=20 > [ ] I think this is too implementation-specific. I suggest we > just remove the sentences regarding archiving and retrieval of media. >=20 > =20 > > 3. Section 3: > > "An SRS is typically implemented as a multi-port device that > > is capable of receiving media from several sources=20 > simultaneously." > > The word "several" seems to suggest a small number. I would=20 > suggest we > > change "several" to "multiple". >=20 > [ ] done. > =20 > > 4. Section 3: > > "An SRS is typically also the sink of the recorded session=20 > metadata." > > Delete the word "typically" - I don't think we have any=20 > other model in > > mind. >=20 > [ ] done. > =20 > > 5. Section 3: > > "Communication Session (CS): A session created between two=20 > or more SIP > > User Agents (UAs) that is the target for recording." > > Change "target for recording" to "subject of recording". >=20 > [ ] done. > =20 > > 6. Section 4: > > As a general comment, there are several incomplete sentences, e.g.: > > - Use case 3 "One or more Recording Sessions per Communication > Session:" > > (no verb) > [ ] This was actually supposed to be a description of the > diagram, but it doesn't read that way so I've fixed it. >=20 > > - Use case 9 "Record a call that is associated with another=20 > call." (no > > subject) > [ ] cleaned up entire description of use case. >=20 > > - Use case 12 "Recording and real-time analytics of trading floor > > interactions > > (including video and instant messaging)." (no verb) >=20 > [ ] cleaned up entire description of use case. > =20 > > 7. Section 4, use case 4: > > "or in > > parallel (Fig. 7)" > > The figure number is wrong (should be figure 6), but I suggest we > delete > > these words. The subject of parallel CSs is introduced in the > paragraph > > immediately preceding figure 6, so we don't need to mention it here. > [ ] done. >=20 > >=20 > > 8. Section 4, use case 4: > > "A Recording Session records continuously without interruption. > > Silent periods must be reproduced upon playback (e.g. by=20 > recording > > the silent period, by not recording the silent periods=20 > but marking > > them as metadata for a player to utilize, etc.)" > > I think the point we are trying to make with use case 4 is=20 > that the RS > > exists even when there is no CS - so it is more than just a silent > period. > > I would reword as: > > "A Recording Session records continuously without interruption. > Periods > > when there is no CS in progress must be reproduced upon=20 > playback (e.g. > by > > recording silence during such periods or by not recording=20 > such periods > but > > marking them by means of metadata for utilization on=20 > playback, etc.)." > >=20 > > 9. Section 4, use case 4: > > "The connection and attributes of media in the Recording Session are > > not dynamically signaled for each Communication Session before it > can > > be recorded; however, codec re-negotiation is possible. =20 > CS details > > and CS metadata will still be signaled, and can be correlated to > the > > recorded media. There will still need to be a means of=20 > correlating > > the recorded media connection/packets to the Communication > Session." > > I think the whole paragraph is getting into solution and could be > omitted. >=20 > [ ] done. > =20 > > 10. Section 4, use case 5: > > "One solution is to not record a caller > > speaking their credit card information." > > Why is not recording just one solution to "not capturing" (in the > first > > sentence of the paragraph)? It seems to me it is the ONLY solution. > Clearly > > you could record and then prevent playback, but then you=20 > have captured > the > > information. >=20 > [ ] PCI compliance is just one example of an application that > may require=20 > protecting customer information. Not capturing that information is one > way to protect it. Other possible solutions include encryption or > post-call redaction. > =20 > > 11. Section 4, use case 7: > > "Many agents and enterprise workers are not located on company > > premises." > > To make it clearer: > > "Many agents and enterprise workers whose calls are to be=20 > recorded are > not > > located on company > > premises." >=20 > [ ] Done. > =20 > > 12. Section 4, use case 8: > > "Internal calls inside or between branches must be recorded." > > Why do only internal calls need recording? Should it say: > > "Internal calls inside or between branches must be recorded, as well > as > > calls involving the central office and external calls." > >=20 > > 13. Section 4, use case 8: > > "Global banks with multiple branches up to thousands of small sites. > > o Only phones and network infrastructure in branches, no=20 > recording > > services. > > o Internal calls inside or between branches must be recorded. > > o Centralized recording system in data centers together with > > telephony infrastructure (e.g. PBX)." > > The three bullets don't seem to form a coherent set. The first and > last > > describe the topology and the second describes recording needs. >=20 > [ ] Reworded: >=20 > Enterprises such as banks, insurance agencies, and retail stores may > have many locations,=20 > possibly up to thousands of small sites. Frequently only phones > and network infrastructure are > installed in branches, without local recording services. In > cases where calls inside or between=20 > branches must be recorded, a centralized recording system in > data centers together with > telephony infrastructure (e.g. PBX) me deployed. > =20 > > 14. Section 4, use case 9: > > "Record a call that is associated with another call." > > Apart from the fact this is not a complete sentence (see earlier > comment), > > I think the point we should be making is that both calls=20 > are recorded, > > together with some means of associating them. >=20 > [ ] reworded. >=20 > =20 > > 15. Section 4, use case 10: > > "o The Communication Session must be terminated (or suitable > > notification) in the event of a recording failure." > > Change "or suitable notification" to "or suitable notification given > to > > parties". >=20 > [ ] done. >=20 > > 16. Section 4, use case 11: > > "In trading floors environments, in order to save=20 > resources, it may be > > preferable to mix multiple concurrent calls (Communication > Sessions) > > on different handsets/speakers on the same turret into single > > recording session." > > It is unclear what resources this really saves, unless you also mix > the > > media from the several CSs into a single media stream on=20 > the RS. Some > > clarification would be useful. >=20 > [ ] clarified that the resources are storage and recording > system resources. > =20 > > 17. Section 4, use case 12: > > "Recorder must support real-time media processing, such as speech > > analytics." > > I think this should say "It must be possible for a recorder to > support...". >=20 > [ ] done. > =20 > >=20 > > Nits: > > 18. Expand the following acronyms on first use: DTMF, ASR. >=20 > [ ] removed acronyms (unnecessary detail) > =20 > > 19. Section 4, use case 4: > > "in sequence (Fig. 6)" > > This should be figure 5. >=20 > [ ] fixed as part of earlier change (above) > =20 > > 20. Section 4, use case 4: > > "The length of a Persistent Recording Sessions " > > Change "Sessions" to "Session". >=20 > [ ] done. > =20 > > 21. Section 4, use case 7: > > "i.e. insurance agents, > > brokers, physicians." > > Change "i.e." to "e.g.". >=20 > [ ] done. > =20 > > 22. Section 4, use case 11: > > "Media is synchronized" > > Change "is" to "are". >=20 > [ ] done. > =20 > > 23. Section 4, use case 12: > > "(stopping interaction or alert)" > > Change "alert" to "alerting". >=20 > [ ] done. >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = From john.elwell@siemens-enterprise.com Tue Jan 25 14:21:19 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D26663A6899 for ; Tue, 25 Jan 2011 14:21:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKziJDSsYksN for ; Tue, 25 Jan 2011 14:21:15 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id D8C1C3A68B6 for ; Tue, 25 Jan 2011 14:21:14 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3143236 for siprec@ietf.org; Tue, 25 Jan 2011 23:24:12 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id D15941EB82AB for ; Tue, 25 Jan 2011 23:24:12 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 25 Jan 2011 23:24:12 +0100 From: "Elwell, John" To: "siprec@ietf.org" Date: Tue, 25 Jan 2011 23:24:11 +0100 Thread-Topic: Minutes day 1 Thread-Index: Acu83pcEUtR/mjUXQMit9DldGQtWeQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Minutes day 1 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 22:21:19 -0000 Minutes of the SIPREC WG Interim Virtual Meeting 2011-01-25, 15.00-17.00 GMT/UTC and 2011-01-25, 14.00-16.00 GMT/UTC =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Meeting chaired by Brian Rosen and John Elwell. Participants (session 1): Brian Rosen, John Elwell, Ken Rehor, Leon Portman= , Henry Lum, Ram=20 Mohen, Andy Hutton, Alan Johnston, Gonzalo Camarillo, Paul Kyzivat, Dave Sm= ith, Parthasarathi, Dan Romascanu, Alissa Cooper, Charles Eckel Minutes produced by John Elwell. Webex chat: See end of these minutes. Jabber was not used. Recording day 1: https://workgreen.webex.com/workgreen/ldr.php?AT=3Dpb&SP= =3DMC&rID=3D8263017&rKey=3D19329980a044b45b=20 Meeting started at 15.02. Topic - Administrivia (chairs) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Slides: http://kenrehor.com/ietf/siprec/IETF79.2/Chairs.pdf No changes to published agenda. Topic - Requirements (Ken Rehor) draft-ietf-siprec-req-06 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-req/ Slides: http://kenrehor.com/ietf/siprec/IETF79.2/IETF-79.2-SIPREC-Req-2011-= 01-25.pdf Slide 4 - proposal to delete REQ-015/016. It was noted that these requirem= ents talk about "cancel and discard". After some discussion, there seemed t= o be agreement that the "cancel" part was covered by other requirements (e.= g., you can pause and not resume, effectively cancelling). So the main issu= e concerned the "discard" part. It was noted that previous agreements relat= ing to privacy had reached the conclusion that the retention of recordings = is an issue for the SRS, and outside the scope of SIPREC. There was no obje= ction to deleting the two requirements. Although the main focus of the requirements is on what happens on the SRC-S= RS interface, Dave Smith brought up the question of whether a participant, = whose SIP UA might not be collocated with the SRC, can request the pausing = / stopping of a recording, or even request deletion of the recording. This = would be a requirement impacting the CS, as opposed to the RS, and it was n= oted that none of the solution work has touched on that (although the earli= er draft from Alan Johnston did have provision for an indication on the CS= signalling path that recording is taking place, but this was not brought f= orward into the present protocol draft). Dave was invited to raise on the l= ist any fresh requirements concerning what CS participants might be able to= request. Slide 5 - proposed new requirement on multiple media streams for the same m= edia type. It was observed that REQ-010 was probably intended to cover this= case, and Ken will propose words to enhance REQ-010 to make it clearer. Slide 6 - removal of REQ-021. There was no objection to removal. Ken will try to seek resolution of the issues above and then publish -07, w= hich should be very close to being ready to submit to the IESG. Topic - Metadata model (Ram Mohan) draft-ram-siprec-metadata-03 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Draft: https://datatracker.ietf.org/doc/draft-ram-siprec-metadata/ Slides: ???? Slide 4: Ram explained why an association between Media Stream and CS had b= een introduced, because of the injection of things like music on hold, lead= ing to a media stream without participant. Charles wondered why music on ho= ld could not be considered a participant. Ram and Paul explained there were= also conference cases where a participant might host a conference on his d= evice, but those behind the conferencing device might not be considered CS = participants. Charles asked why the conference focus could not be considere= d a participant. Paul explained that the SRC could obtain, using the confer= ence event package, a list of participants from the focus, and those partic= ipants would contribute to the media stream, but those participants would n= ot be part of the CS - that would be the role of the focus. Henry thought a= mixer might be considered a participant, but Paul explained that if you ca= n obtain a roster of people behind the mixer, those might be considered par= ticipants rather than the mixer. So there can be participants in the media = that are not participants in the CS. Charles was worried that some media st= reams might not have any identified participants who are generating the str= eam. Paul explained that, assuming the media from the participants are mixe= d, you would see one media stream and a list of participants. One participa= nt might be joined to the CS and the others would not be. Paul thinks we ne= ed to explore some use cases and see how they would be represented using th= is model. So if people have particular use cases, make them known and we ch= eck how they would be represented. Ram will solicit use cases. Partha also = had concerns similar to those of Charles, but Charles was beginning to see = how the present model might work if you can get information about non-CS pa= rticipants who are generating a media stream. Paul pointed out that the mod= el does cater for a participant that is not part of a CS. Charles was invit= ed to post his continued concerns / scenarios to the list, but Paul thinks = the use cases concerned are already covered by the model. Slide 6 (CS Group): Nobody on list had come up with a reason for having mor= e than one CSG associated with a single CS, and the conclusion reached on t= he list seems to stand. Slide 7 (CS): No comments on CS slide, except that forced deletion is to be= removed in line with the requirements discussion. Slide 8 (Participant): Clarified that the multiple AORs are aliases, in the= sense of P-Asserted-Identity being able to carry aliases. Concerning the issue of whether participant role is needed as an attribute,= Leon suggested it could be done in application data, but asked whether we = would then publish some application data dictionary. Paul suggested that ap= plication data is just some additional XML in some other namespace, so some= other group could get together and define it. Leon was concerned that with= out some sort of standardization, different vendors would implement it diff= erently. John suggested we need to decide what things are needed by 80% of = deployments and standardize those in this group, so if that is the case for= participant role, we should standardize it. Partha wanted to include parti= cipant role, even though there might be some cases where it is not availabl= e. Paul pointed out that we had had considerable list discussion on the dif= ficulties of figuring out the role: UAC/UAS is transaction specific, inboun= d/outbound is problematic, and incoming/outgoing, whilst it might work in s= ome cases, it will not always work. Perhaps those focused on call centres c= an say what might/might not work. In conclusion, this has to be taken back = to the list. Without repeating the old arguments, those wanting to include = participant role should indicate what are the likely mechanisms that might = support it. Slide 10 (Media Stream): How to model media streams that are not recorded (= rejected by SRS or no capability at SRS). Dave thought was important that y= ou have some information in the metadata that there was media that was avai= lable for recording but couldn't be recorded, but there are two cases: wher= e you don't want to record, or where because of a temporary limitation you = are unable to record but might want to record later. Paul agreed, but was c= oncerned about the details, although that is very much down to the mechanis= m, e.g., does the SRC need to keep offering the stream? Partha asked a question on start time and end time. Ram clarified this is t= hese are start and end times of the CS media. It was pointed out that we ha= ve wall clock time in the metadata, and other times can be relative. Leon s= uggested there may be a need to retransmit wall clock time occasionally, to= compensate for drift. Henry asked whether media stream reference should be part of the mechanism = rather than an attribute. Slide 10 (Application data): Leon agreed with the extensible approach, base= d on different namespaces. Paul said that he would be tempted to stop calli= ng it application data and call it extension data. John (from the floor) qu= estioned whether it really is an object, or just attributes of other object= s. Paul said it was just an artefact of how the model is drawn, but in the = solution it would just be extensibility data. The authors will rework this = with these comments in mind. On next steps, people are asked to review and submit further comments on -0= 3, and -04 will be produced in due course, after which we might be consider= adoption as a WG item. In particular, we need closure on the long discussi= on of media stream relationships. Topic - Protocol (Henry Lum / Leon Portman) draft-portman-siprec-protocol-02 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Draft: https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ Slides: http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20- %20virtual%20interim%20Dec%2016%202010.pdf Slide 4 (Persistent recording): Leon pointed out that the whole idea of per= sistent recording is not to spend time negotiating m-lines when a CS starts= - so he prefers the second option on the slide. For SRCs that support a la= rge number of parallel CSs, the SRC could pre-negotiate a large number of m= -lines (perhaps based on licensing), rather like provisioning trunks. Paul = felt that the other option should be kept open - a slight delay in negotiat= ing a new m-line could be handled by transmitting the data slightly delayed= , without losing any. Henry also mentioned the possibility of the offer-ans= wer failing. It was questioned whether there needs to be something in the p= rotocol to indicate the delay. This issue should be brought to the list. Day 1 wrap-up =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D It was agreed that on the second day we will start by completing the Protoc= ol topic and then do the metadata format topic. The meeting was closed at 17.00. Day 1 chat log =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D January 25, 2011 3:19:58 PM from Alissa Cooper to Everyone: I'm not in a place where I can speak in the audio, but I thin= k we decided not to have requirements related to what happens to the record= ing after it has been made. January 25, 2011 3:30:32 PM from Alissa Cooper to Everyone: it seems like there are cases where the hints are valuable ev= en if they aren't always honoured January 25, 2011 3:39:51 PM from Alissa Cooper to Everyone: it's old, I'll take it to the list January 25, 2011 4:59:32 PM from Kenneth Rehor to Everyone: Unfortunately I have to drop off now. TTY tomorrow. From partr@cisco.com Tue Jan 25 17:02:41 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F02E3A68F9 for ; Tue, 25 Jan 2011 17:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.186 X-Spam-Level: X-Spam-Status: No, score=-10.186 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8cz+M5PGxKX for ; Tue, 25 Jan 2011 17:02:40 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E84B03A68F7 for ; Tue, 25 Jan 2011 17:02:39 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4EANABP02Q/khLgWdsb2JhbACkcRUBAQsLIiSeMps9hU8EhRWKXw Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 26 Jan 2011 01:05:38 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p0Q15Q78026683; Wed, 26 Jan 2011 01:05:37 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Jan 2011 06:35:26 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Jan 2011 06:32:32 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Persistent RS session with large set of CS info Thread-Index: Acu83pcEUtR/mjUXQMit9DldGQtWeQAD1xmg From: "Parthasarathi R (partr)" To: , "Leon Portman" , "Henry Lum" X-OriginalArrivalTime: 26 Jan 2011 01:05:26.0281 (UTC) FILETIME=[1DC76F90:01CBBCF5] Subject: [siprec] Persistent RS session with large set of CS info X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 01:02:41 -0000 Leon/Henry, The proposal of pre-negotiate large of m-lines in case SRC supports large number of sessions is not a optimal solution for the following reason: 1) Maintaining such a large number of m-line will be an architecture challenge in as SRC would have maintained very few m-line till recording feature is implemented. Let take 200 session supported in SRC then 400 m-lines has to be maintained in case of unmixed recording of audio for two party call and 800 m-lines in case of recording unmixed audio & video call for two party call.=20 2) As John pointed out in another mail thread, it is not possible to remove m-line once it is created in persistent RS. 3) SRC wastes its resources when the number of recording session is lower. In case SRC performs lot more services apart from recording, huge performance impact will be seen in SRC as the resources are pre-occupied for persistent RS.=20 In the earlier mail, I have proposed to create pre-allocated pool of persistent RS for SRC which handle large number sessions. Each RS is associated with one CS group (CSG) whenever CSG is created, RS is freed from CSG when CSG is terminated and RS is re-used for another CSG later. Here, persistent RS allocation/de-allocation is implementation-dependent and the resource optimization is possible based on implementation. =20 I agree that pre-negotiated persistent RS works for end-point which acts as SRC and may work for SRC with few (2-5) sessions. Please let me know your opinion here. Thanks Partha Topic - Protocol (Henry Lum / Leon Portman) draft-portman-siprec-protocol-02 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Draft: https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ Slides: http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20- %20virtual%20interim%20Dec%2016%202010.pdf Slide 4 (Persistent recording): Leon pointed out that the whole idea of persistent recording is not to spend time negotiating m-lines when a CS starts - so he prefers the second option on the slide. For SRCs that support a large number of parallel CSs, the SRC could pre-negotiate a large number of m-lines (perhaps based on licensing), rather like provisioning trunks. Paul felt that the other option should be kept open - a slight delay in negotiating a new m-line could be handled by transmitting the data slightly delayed, without losing any. Henry also mentioned the possibility of the offer-answer failing. It was questioned whether there needs to be something in the protocol to indicate the delay. This issue should be brought to the list. From krehor@cisco.com Tue Jan 25 23:03:44 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 959E13A694D for ; Tue, 25 Jan 2011 23:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.489 X-Spam-Level: X-Spam-Status: No, score=-10.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIjyButKTrfT for ; Tue, 25 Jan 2011 23:03:43 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id A23373A6946 for ; Tue, 25 Jan 2011 23:03:43 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgFAONWP01AaMHG/2dsb2JhbACCQJQUjh9zoQubPIVPBIUXil4 Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-2.cisco.com with ESMTP; 26 Jan 2011 07:06:42 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0Q76fhL011864 for ; Wed, 26 Jan 2011 07:06:41 GMT Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Jan 2011 23:06:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBBD27.94B39C70" Date: Tue, 25 Jan 2011 23:06:36 -0800 Message-ID: <7744FE52C78D944587F03773EB4514610950F6A3@xmb-sjc-22e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: revised REQ-010 Thread-Index: Acu9J5IVPCoXGIduQ0K4HgOna9O+vw== From: "Ken Rehor (krehor)" To: X-OriginalArrivalTime: 26 Jan 2011 07:06:41.0082 (UTC) FILETIME=[94F799A0:01CBBD27] Subject: [siprec] revised REQ-010 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 07:03:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBBD27.94B39C70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 The following is a proposal to change REQ-010. The existing requirement is: =20 o REQ-010 The mechanism MUST support the ability to deliver to the SRS multiple media streams for a given CS. =20 The proposed new version is: =20 o REQ-010 The mechanism MUST support the ability to deliver to the SRS multiple media streams of the same or different media types for a given CS. =20 =20 Ken =20 =20 For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 ------_=_NextPart_001_01CBBD27.94B39C70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

The = following is a proposal to change REQ-010. The existing requirement = is:

 

o = REQ-010 The mechanism MUST support the ability to deliver to = the

   SRS multiple media streams for a given = CS.

 

The proposed new version is:

 

o REQ-010 The =
mechanism MUST support the ability to deliver to =
the
   SRS multiple media streams of the =
same or different media types for a given CS.

 

 

Ken

 

 

For corporate = legal information go = to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 

------_=_NextPart_001_01CBBD27.94B39C70-- From trac@tools.ietf.org Tue Jan 25 23:04:14 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0BD23A694F for ; Tue, 25 Jan 2011 23:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Vb38Who+PFK for ; Tue, 25 Jan 2011 23:04:13 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 639F53A694D for ; Tue, 25 Jan 2011 23:04:12 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PhzTC-0008QZ-Kw; Tue, 25 Jan 2011 23:07:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "siprec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: leon.portman@nice.com, krehor@cisco.com X-Trac-Project: siprec Date: Wed, 26 Jan 2011 07:07:10 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/siprec/trac/ticket/62#comment:1 Message-ID: <084.5a88ed7eea797d7d078a2c3ee390e27c@tools.ietf.org> References: <075.7ae0cea02995133f0fb581b76b53faba@tools.ietf.org> X-Trac-Ticket-ID: 62 In-Reply-To: <075.7ae0cea02995133f0fb581b76b53faba@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: leon.portman@nice.com, krehor@cisco.com, siprec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: siprec@ietf.org Subject: Re: [siprec] Requirements #62 (closed): Do we still need REQ-015 and REQ-016? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 07:04:15 -0000 #62: Do we still need REQ-015 and REQ-016? Changes (by krehor@…): * status: new => closed * resolution: => fixed Comment: To be resolved in -07 draft. -- ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: leon.portman@… Type: defect | Status: closed Priority: minor | Milestone: Component: Requirements | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | ------------------------------------------------+--------------------------- Ticket URL: siprec From john.elwell@siemens-enterprise.com Tue Jan 25 23:22:39 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91A293A693F for ; Tue, 25 Jan 2011 23:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peknmfvHq18Y for ; Tue, 25 Jan 2011 23:22:38 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 479963A6939 for ; Tue, 25 Jan 2011 23:22:37 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3143608; Wed, 26 Jan 2011 08:25:37 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 4EDB31EB82AB; Wed, 26 Jan 2011 08:25:37 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 26 Jan 2011 08:25:37 +0100 From: "Elwell, John" To: "Ken Rehor (krehor)" , "siprec@ietf.org" Date: Wed, 26 Jan 2011 08:25:36 +0100 Thread-Topic: revised REQ-010 Thread-Index: Acu9J5IVPCoXGIduQ0K4HgOna9O+vwAAp4FQ Message-ID: References: <7744FE52C78D944587F03773EB4514610950F6A3@xmb-sjc-22e.amer.cisco.com> In-Reply-To: <7744FE52C78D944587F03773EB4514610950F6A3@xmb-sjc-22e.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] revised REQ-010 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 07:22:39 -0000 WFM John=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Ken Rehor (krehor) > Sent: 26 January 2011 07:07 > To: siprec@ietf.org > Subject: [siprec] revised REQ-010 >=20 > =20 >=20 > The following is a proposal to change REQ-010. The existing=20 > requirement is: >=20 > =20 >=20 > o REQ-010 The mechanism MUST support the ability to deliver to the >=20 > SRS multiple media streams for a given CS. >=20 > =20 >=20 > The proposed new version is: >=20 > =20 >=20 > o REQ-010 The mechanism MUST support the ability to deliver to the > SRS multiple media streams of the same or different media=20 > types for a given CS. >=20 > =20 >=20 > =20 >=20 > Ken >=20 > =20 >=20 > =20 >=20 > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 > =20 >=20 > = From john.elwell@siemens-enterprise.com Tue Jan 25 23:23:04 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1DF63A6942 for ; Tue, 25 Jan 2011 23:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUINgYKRRJwI for ; Tue, 25 Jan 2011 23:23:02 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 904383A6939 for ; Tue, 25 Jan 2011 23:23:01 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3137261; Wed, 26 Jan 2011 08:24:39 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 5045923F0278; Wed, 26 Jan 2011 08:24:39 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 26 Jan 2011 08:24:39 +0100 From: "Elwell, John" To: "Parthasarathi R (partr)" , "siprec@ietf.org" , Leon Portman , Henry Lum Date: Wed, 26 Jan 2011 08:24:37 +0100 Thread-Topic: Persistent RS session with large set of CS info Thread-Index: Acu83pcEUtR/mjUXQMit9DldGQtWeQAD1xmgAA7KipA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Persistent RS session with large set of CS info X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 07:23:04 -0000 I tend to agree with Partha's concerns on scalability. Perhaps separate per= sistent RSs would be preferable, rather than a single persistent RS with a = large/huge number of pre-allocated m-lines. A persistent RS supporting more= than 1 parallel CS might be feasible for a very small number of CSs, as mi= ght be encountered at a user's device, so it might be worth retaining the c= oncept. Or we could say that an RS must not support more than one parallel = CS, thereby forcing separate RSs for parallel CSs. I am not sure I understand the need to bring CS-Group into the solution. Di= fferent CSs from the same CS-Group could use the same RS or different RSs -= it shouldn't matter. John (as individual) > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) > Sent: 26 January 2011 01:03 > To: siprec@ietf.org; Leon Portman; Henry Lum > Subject: [siprec] Persistent RS session with large set of CS info >=20 > Leon/Henry, >=20 > The proposal of pre-negotiate large of m-lines in case SRC supports > large number of sessions is not a optimal solution for the following > reason: >=20 > 1) Maintaining such a large number of m-line will be an architecture > challenge in as SRC would have maintained very few m-line=20 > till recording > feature is implemented. Let take 200 session supported in=20 > SRC then 400 > m-lines has to be maintained in case of unmixed recording of audio for > two party call and 800 m-lines in case of recording unmixed audio & > video call for two party call.=20 >=20 > 2) As John pointed out in another mail thread, it is not possible to > remove m-line once it is created in persistent RS. >=20 > 3) SRC wastes its resources when the number of recording session is > lower. In case SRC performs lot more services apart from=20 > recording, huge > performance impact will be seen in SRC as the resources are=20 > pre-occupied > for persistent RS.=20 >=20 > In the earlier mail, I have proposed to create pre-allocated pool of > persistent RS for SRC which handle large number sessions. Each RS is > associated with one CS group (CSG) whenever CSG is created,=20 > RS is freed > from CSG when CSG is terminated and RS is re-used for another=20 > CSG later. > Here, persistent RS allocation/de-allocation is=20 > implementation-dependent > and the resource optimization is possible based on implementation. =20 >=20 > I agree that pre-negotiated persistent RS works for end-point=20 > which acts > as SRC and may work for SRC with few (2-5) sessions. >=20 > Please let me know your opinion here. >=20 > Thanks > Partha >=20 > Topic - Protocol (Henry Lum / Leon Portman) > draft-portman-siprec-protocol-02 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Draft: https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ > Slides: http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20- > %20virtual%20interim%20Dec%2016%202010.pdf >=20 > Slide 4 (Persistent recording): Leon pointed out that the=20 > whole idea of > persistent recording is not to spend time negotiating m-lines=20 > when a CS > starts - so he prefers the second option on the slide. For SRCs that > support a large number of parallel CSs, the SRC could pre-negotiate a > large number of m-lines (perhaps based on licensing), rather like > provisioning trunks. Paul felt that the other option should=20 > be kept open > - a slight delay in negotiating a new m-line could be handled by > transmitting the data slightly delayed, without losing any. Henry also > mentioned the possibility of the offer-answer failing. It was=20 > questioned > whether there needs to be something in the protocol to indicate the > delay. This issue should be brought to the list. >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From partr@cisco.com Wed Jan 26 01:31:55 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 898893A6975 for ; Wed, 26 Jan 2011 01:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.495 X-Spam-Level: X-Spam-Status: No, score=-9.495 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pg5J5pLT9R9L for ; Wed, 26 Jan 2011 01:31:53 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0E0F73A6958 for ; Wed, 26 Jan 2011 01:31:52 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIGAFd5P02Q/khLgWdsb2JhbACcXIc3YxUBAQsLIiSgdps9hU8EhRWKYA Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 26 Jan 2011 09:34:52 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p0Q9Yptm026578; Wed, 26 Jan 2011 09:34:51 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Jan 2011 15:04:51 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBBD3C.2F5E4AAB" Date: Wed, 26 Jan 2011 15:04:10 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Persistent RS session with large set of CS info Thread-Index: Acu83pcEUtR/mjUXQMit9DldGQtWeQAD1xmgAA7KipAABHZ9mA== References: From: "Parthasarathi R (partr)" To: "Elwell, John" , , "Leon Portman" , "Henry Lum" X-OriginalArrivalTime: 26 Jan 2011 09:34:51.0323 (UTC) FILETIME=[47F6B8B0:01CBBD3C] Subject: Re: [siprec] Persistent RS session with large set of CS info X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 09:31:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBBD3C.2F5E4AAB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable John, =20 Please read inline. =20 Thanks Partha ________________________________ From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] Sent: Wed 1/26/2011 12:54 PM To: Parthasarathi R (partr); siprec@ietf.org; Leon Portman; Henry Lum Subject: RE: Persistent RS session with large set of CS info I tend to agree with Partha's concerns on scalability. Perhaps separate = persistent RSs would be preferable, rather than a single persistent RS = with a large/huge number of pre-allocated m-lines. A persistent RS = supporting more than 1 parallel CS might be feasible for a very small = number of CSs, as might be encountered at a user's device, so it might = be worth retaining the concept. Or we could say that an RS must not = support more than one parallel CS, thereby forcing separate RSs for = parallel CSs. we will discuss about this solution approach in detail during = today's meeting and try to bring the closure I am not sure I understand the need to bring CS-Group into the solution. = Different CSs from the same CS-Group could use the same RS or different = RSs - it shouldn't matter. Sorry in case I confused. As you mentioned, there is no = restriction w.r.t single CSG in single RS or single CSG in multiple RS = and it does not matter. I just provided the example wherein each RS may = use same CSG. =20 John (as individual) > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) > Sent: 26 January 2011 01:03 > To: siprec@ietf.org; Leon Portman; Henry Lum > Subject: [siprec] Persistent RS session with large set of CS info > > Leon/Henry, > > The proposal of pre-negotiate large of m-lines in case SRC supports > large number of sessions is not a optimal solution for the following > reason: > > 1) Maintaining such a large number of m-line will be an architecture > challenge in as SRC would have maintained very few m-line > till recording > feature is implemented. Let take 200 session supported in > SRC then 400 > m-lines has to be maintained in case of unmixed recording of audio for > two party call and 800 m-lines in case of recording unmixed audio & > video call for two party call. > > 2) As John pointed out in another mail thread, it is not possible to > remove m-line once it is created in persistent RS. > > 3) SRC wastes its resources when the number of recording session is > lower. In case SRC performs lot more services apart from > recording, huge > performance impact will be seen in SRC as the resources are > pre-occupied > for persistent RS. > > In the earlier mail, I have proposed to create pre-allocated pool of > persistent RS for SRC which handle large number sessions. Each RS is > associated with one CS group (CSG) whenever CSG is created, > RS is freed > from CSG when CSG is terminated and RS is re-used for another > CSG later. > Here, persistent RS allocation/de-allocation is > implementation-dependent > and the resource optimization is possible based on implementation.=20 > > I agree that pre-negotiated persistent RS works for end-point > which acts > as SRC and may work for SRC with few (2-5) sessions. > > Please let me know your opinion here. > > Thanks > Partha > > Topic - Protocol (Henry Lum / Leon Portman) > draft-portman-siprec-protocol-02 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Draft: https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ > Slides: http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20- > %20virtual%20interim%20Dec%2016%202010.pdf > > Slide 4 (Persistent recording): Leon pointed out that the > whole idea of > persistent recording is not to spend time negotiating m-lines > when a CS > starts - so he prefers the second option on the slide. For SRCs that > support a large number of parallel CSs, the SRC could pre-negotiate a > large number of m-lines (perhaps based on licensing), rather like > provisioning trunks. Paul felt that the other option should > be kept open > - a slight delay in negotiating a new m-line could be handled by > transmitting the data slightly delayed, without losing any. Henry also > mentioned the possibility of the offer-answer failing. It was > questioned > whether there needs to be something in the protocol to indicate the > delay. This issue should be brought to the list. > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > ------_=_NextPart_001_01CBBD3C.2F5E4AAB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Persistent RS session with large set of = CS info=0A= =0A= =0A= =0A=
=0A=
John,
=0A=
 
=0A=
Please read = inline.
=0A=
 
=0A=
Thanks
=0A=
Partha
=0A=

=0A=
=0A= From: Elwell, John = [mailto:john.elwell@siemens-enterprise.com]
Sent: Wed = 1/26/2011 12:54 PM
To: Parthasarathi R (partr); = siprec@ietf.org; Leon Portman; Henry Lum
Subject: RE: = Persistent RS session with large set of CS info

=0A=
=0A=

I tend to agree with Partha's concerns on scalability. = Perhaps separate persistent RSs would be preferable, rather than a = single persistent RS with a large/huge number of pre-allocated m-lines. = A persistent RS supporting more than 1 parallel CS might be feasible for = a very small number of CSs, as might be encountered at a user's device, = so it might be worth retaining the concept. Or we could say that an RS = must not support more than one parallel CS, thereby forcing separate RSs = for parallel CSs.

=0A=

<Partha> we will discuss about this solution = approach in detail during today's meeting and try to = bring the closure </Partha>

I am not sure I understand = the need to bring CS-Group into the solution. Different CSs from the = same CS-Group could use the same RS or different RSs - it shouldn't = matter.

=0A=

<Partha> Sorry in case I confused. As you = mentioned, there is no restriction w.r.t single CSG in single RS or = single CSG in multiple RS and it does not matter. I just = provided the example wherein each RS may use same CSG. = </Partha>  

=0A=

John (as individual)

> -----Original = Message-----
> From: siprec-bounces@ietf.org
> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr)
> Sent: 26 January 2011 = 01:03
> To: siprec@ietf.org; Leon Portman; Henry Lum
> = Subject: [siprec] Persistent RS session with large set of CS = info
>
> Leon/Henry,
>
> The proposal of = pre-negotiate large of m-lines in case SRC supports
> large number = of sessions is not a optimal solution for the following
> = reason:
>
> 1) Maintaining such a large number of m-line = will be an architecture
> challenge in as SRC would have = maintained very few m-line
> till recording
> feature is = implemented. Let take  200 session supported in
> SRC then = 400
> m-lines has to be maintained in case of unmixed recording of = audio for
> two party call and 800 m-lines in case of recording = unmixed audio &
> video call for two party = call.
>
> 2) As John pointed out in another mail thread, it = is not possible to
> remove m-line once it is created in = persistent RS.
>
> 3) SRC wastes its resources when the = number of recording session is
> lower. In case SRC performs lot = more services apart from
> recording, huge
> performance = impact will be seen in SRC as the resources are
> = pre-occupied
> for persistent RS.
>
> In the earlier = mail, I have proposed to create pre-allocated pool of
> persistent = RS for SRC which handle large number sessions. Each RS is
> = associated with one CS group (CSG) whenever CSG is created,
> RS = is freed
> from CSG when CSG is terminated and RS is re-used for = another
> CSG later.
> Here, persistent RS = allocation/de-allocation is
> implementation-dependent
> and = the resource optimization is possible based on = implementation. 
>
> I agree that pre-negotiated = persistent RS works for end-point
> which acts
> as SRC and = may work for SRC with few (2-5) sessions.
>
> Please let me = know your opinion here.
>
> Thanks
> = Partha
>
> Topic - Protocol (Henry Lum / Leon = Portman)
> draft-portman-siprec-protocol-02
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
= > Draft: = https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/
&g= t; Slides: h= ttp://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20-
>= %20virtual%20interim%20Dec%2016%202010.pdf
>
> Slide 4 = (Persistent recording): Leon pointed out that the
> whole idea = of
> persistent recording is not to spend time negotiating = m-lines
> when a CS
> starts - so he prefers the second = option on the slide. For SRCs that
> support a large number of = parallel CSs, the SRC could pre-negotiate a
> large number of = m-lines (perhaps based on licensing), rather like
> provisioning = trunks. Paul felt that the other option should
> be kept = open
> - a slight delay in negotiating a new m-line could be = handled by
> transmitting the data slightly delayed, without = losing any. Henry also
> mentioned the possibility of the = offer-answer failing. It was
> questioned
> whether there = needs to be something in the protocol to indicate the
> delay. = This issue should be brought to the list.
>
> = _______________________________________________
> siprec mailing = list
> siprec@ietf.org
> https://www.ietf.or= g/mailman/listinfo/siprec
>

------_=_NextPart_001_01CBBD3C.2F5E4AAB-- From Leon.Portman@nice.com Wed Jan 26 04:38:58 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EECF3A68AB for ; Wed, 26 Jan 2011 04:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltgYGgF0c-cy for ; Wed, 26 Jan 2011 04:38:56 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id 3933B3A63C9 for ; Wed, 26 Jan 2011 04:34:41 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Wed, 26 Jan 2011 14:37:30 +0200 From: Leon Portman To: "'partr@cisco.com'" , "'john.elwell@siemens-enterprise.com'" , "'siprec@ietf.org'" , "'Henry.Lum@alcatel-lucent.com'" Date: Wed, 26 Jan 2011 14:37:29 +0200 Thread-Topic: Persistent RS session with large set of CS info Thread-Index: Acu83pcEUtR/mjUXQMit9DldGQtWeQAD1xmgAA7KipAABHZ9mAAGtQ0e Message-ID: <07465C1D981ABC41A344374066AE1A2C389F4A5B6B@TLVMBX01.nice.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_07465C1D981ABC41A344374066AE1A2C389F4A5B6BTLVMBX01nicec_" MIME-Version: 1.0 Subject: Re: [siprec] Persistent RS session with large set of CS info X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 12:38:58 -0000 --_000_07465C1D981ABC41A344374066AE1A2C389F4A5B6BTLVMBX01nicec_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgd2FzIG5vIGludGVudCB0byBsaW1pdCBudW1iZXIgb2YgbS1saW5lcyBwZXIgUlMuIEl0 IGlzIG1vcmUgaW1wbGVtZW50YXRpb24gZGVjaXNpb24gdG8gaGF2ZSBvbmUgZ2lhbnQgUlMgb3Ig bXVsdGlwbGUgUnMgYmxvY2tzLg0KDQpMZW9uDQoNCkZyb206IFBhcnRoYXNhcmF0aGkgUiAocGFy dHIpIFttYWlsdG86cGFydHJAY2lzY28uY29tXQ0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDI2 LCAyMDExIDExOjM0IEFNDQpUbzogRWx3ZWxsLCBKb2huIDxqb2huLmVsd2VsbEBzaWVtZW5zLWVu dGVycHJpc2UuY29tPjsgc2lwcmVjQGlldGYub3JnIDxzaXByZWNAaWV0Zi5vcmc+OyBMZW9uIFBv cnRtYW47IEhlbnJ5IEx1bSA8SGVucnkuTHVtQGFsY2F0ZWwtbHVjZW50LmNvbT4NClN1YmplY3Q6 IFJFOiBQZXJzaXN0ZW50IFJTIHNlc3Npb24gd2l0aCBsYXJnZSBzZXQgb2YgQ1MgaW5mbw0KDQpK b2huLA0KDQpQbGVhc2UgcmVhZCBpbmxpbmUuDQoNClRoYW5rcw0KUGFydGhhDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBFbHdlbGwsIEpvaG4gW21haWx0bzpqb2hu LmVsd2VsbEBzaWVtZW5zLWVudGVycHJpc2UuY29tXQ0KU2VudDogV2VkIDEvMjYvMjAxMSAxMjo1 NCBQTQ0KVG86IFBhcnRoYXNhcmF0aGkgUiAocGFydHIpOyBzaXByZWNAaWV0Zi5vcmc7IExlb24g UG9ydG1hbjsgSGVucnkgTHVtDQpTdWJqZWN0OiBSRTogUGVyc2lzdGVudCBSUyBzZXNzaW9uIHdp dGggbGFyZ2Ugc2V0IG9mIENTIGluZm8NCg0KDQpJIHRlbmQgdG8gYWdyZWUgd2l0aCBQYXJ0aGEn cyBjb25jZXJucyBvbiBzY2FsYWJpbGl0eS4gUGVyaGFwcyBzZXBhcmF0ZSBwZXJzaXN0ZW50IFJT cyB3b3VsZCBiZSBwcmVmZXJhYmxlLCByYXRoZXIgdGhhbiBhIHNpbmdsZSBwZXJzaXN0ZW50IFJT IHdpdGggYSBsYXJnZS9odWdlIG51bWJlciBvZiBwcmUtYWxsb2NhdGVkIG0tbGluZXMuIEEgcGVy c2lzdGVudCBSUyBzdXBwb3J0aW5nIG1vcmUgdGhhbiAxIHBhcmFsbGVsIENTIG1pZ2h0IGJlIGZl YXNpYmxlIGZvciBhIHZlcnkgc21hbGwgbnVtYmVyIG9mIENTcywgYXMgbWlnaHQgYmUgZW5jb3Vu dGVyZWQgYXQgYSB1c2VyJ3MgZGV2aWNlLCBzbyBpdCBtaWdodCBiZSB3b3J0aCByZXRhaW5pbmcg dGhlIGNvbmNlcHQuIE9yIHdlIGNvdWxkIHNheSB0aGF0IGFuIFJTIG11c3Qgbm90IHN1cHBvcnQg bW9yZSB0aGFuIG9uZSBwYXJhbGxlbCBDUywgdGhlcmVieSBmb3JjaW5nIHNlcGFyYXRlIFJTcyBm b3IgcGFyYWxsZWwgQ1NzLg0KDQo8UGFydGhhPiB3ZSB3aWxsIGRpc2N1c3MgYWJvdXQgdGhpcyBz b2x1dGlvbiBhcHByb2FjaCBpbiBkZXRhaWwgZHVyaW5nIHRvZGF5J3MgbWVldGluZyBhbmQgdHJ5 IHRvIGJyaW5nIHRoZSBjbG9zdXJlIDwvUGFydGhhPg0KDQpJIGFtIG5vdCBzdXJlIEkgdW5kZXJz dGFuZCB0aGUgbmVlZCB0byBicmluZyBDUy1Hcm91cCBpbnRvIHRoZSBzb2x1dGlvbi4gRGlmZmVy ZW50IENTcyBmcm9tIHRoZSBzYW1lIENTLUdyb3VwIGNvdWxkIHVzZSB0aGUgc2FtZSBSUyBvciBk aWZmZXJlbnQgUlNzIC0gaXQgc2hvdWxkbid0IG1hdHRlci4NCg0KPFBhcnRoYT4gU29ycnkgaW4g Y2FzZSBJIGNvbmZ1c2VkLiBBcyB5b3UgbWVudGlvbmVkLCB0aGVyZSBpcyBubyByZXN0cmljdGlv biB3LnIudCBzaW5nbGUgQ1NHIGluIHNpbmdsZSBSUyBvciBzaW5nbGUgQ1NHIGluIG11bHRpcGxl IFJTIGFuZCBpdCBkb2VzIG5vdCBtYXR0ZXIuIEkganVzdCBwcm92aWRlZCB0aGUgZXhhbXBsZSB3 aGVyZWluIGVhY2ggUlMgbWF5IHVzZSBzYW1lIENTRy4gPC9QYXJ0aGE+DQoNCkpvaG4gKGFzIGlu ZGl2aWR1YWwpDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc2lwcmVj LWJvdW5jZXNAaWV0Zi5vcmcNCj4gW21haWx0bzpzaXByZWMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIFBhcnRoYXNhcmF0aGkgUiAocGFydHIpDQo+IFNlbnQ6IDI2IEphbnVhcnkgMjAx MSAwMTowMw0KPiBUbzogc2lwcmVjQGlldGYub3JnOyBMZW9uIFBvcnRtYW47IEhlbnJ5IEx1bQ0K PiBTdWJqZWN0OiBbc2lwcmVjXSBQZXJzaXN0ZW50IFJTIHNlc3Npb24gd2l0aCBsYXJnZSBzZXQg b2YgQ1MgaW5mbw0KPg0KPiBMZW9uL0hlbnJ5LA0KPg0KPiBUaGUgcHJvcG9zYWwgb2YgcHJlLW5l Z290aWF0ZSBsYXJnZSBvZiBtLWxpbmVzIGluIGNhc2UgU1JDIHN1cHBvcnRzDQo+IGxhcmdlIG51 bWJlciBvZiBzZXNzaW9ucyBpcyBub3QgYSBvcHRpbWFsIHNvbHV0aW9uIGZvciB0aGUgZm9sbG93 aW5nDQo+IHJlYXNvbjoNCj4NCj4gMSkgTWFpbnRhaW5pbmcgc3VjaCBhIGxhcmdlIG51bWJlciBv ZiBtLWxpbmUgd2lsbCBiZSBhbiBhcmNoaXRlY3R1cmUNCj4gY2hhbGxlbmdlIGluIGFzIFNSQyB3 b3VsZCBoYXZlIG1haW50YWluZWQgdmVyeSBmZXcgbS1saW5lDQo+IHRpbGwgcmVjb3JkaW5nDQo+ IGZlYXR1cmUgaXMgaW1wbGVtZW50ZWQuIExldCB0YWtlICAyMDAgc2Vzc2lvbiBzdXBwb3J0ZWQg aW4NCj4gU1JDIHRoZW4gNDAwDQo+IG0tbGluZXMgaGFzIHRvIGJlIG1haW50YWluZWQgaW4gY2Fz ZSBvZiB1bm1peGVkIHJlY29yZGluZyBvZiBhdWRpbyBmb3INCj4gdHdvIHBhcnR5IGNhbGwgYW5k IDgwMCBtLWxpbmVzIGluIGNhc2Ugb2YgcmVjb3JkaW5nIHVubWl4ZWQgYXVkaW8gJg0KPiB2aWRl byBjYWxsIGZvciB0d28gcGFydHkgY2FsbC4NCj4NCj4gMikgQXMgSm9obiBwb2ludGVkIG91dCBp biBhbm90aGVyIG1haWwgdGhyZWFkLCBpdCBpcyBub3QgcG9zc2libGUgdG8NCj4gcmVtb3ZlIG0t bGluZSBvbmNlIGl0IGlzIGNyZWF0ZWQgaW4gcGVyc2lzdGVudCBSUy4NCj4NCj4gMykgU1JDIHdh c3RlcyBpdHMgcmVzb3VyY2VzIHdoZW4gdGhlIG51bWJlciBvZiByZWNvcmRpbmcgc2Vzc2lvbiBp cw0KPiBsb3dlci4gSW4gY2FzZSBTUkMgcGVyZm9ybXMgbG90IG1vcmUgc2VydmljZXMgYXBhcnQg ZnJvbQ0KPiByZWNvcmRpbmcsIGh1Z2UNCj4gcGVyZm9ybWFuY2UgaW1wYWN0IHdpbGwgYmUgc2Vl biBpbiBTUkMgYXMgdGhlIHJlc291cmNlcyBhcmUNCj4gcHJlLW9jY3VwaWVkDQo+IGZvciBwZXJz aXN0ZW50IFJTLg0KPg0KPiBJbiB0aGUgZWFybGllciBtYWlsLCBJIGhhdmUgcHJvcG9zZWQgdG8g Y3JlYXRlIHByZS1hbGxvY2F0ZWQgcG9vbCBvZg0KPiBwZXJzaXN0ZW50IFJTIGZvciBTUkMgd2hp Y2ggaGFuZGxlIGxhcmdlIG51bWJlciBzZXNzaW9ucy4gRWFjaCBSUyBpcw0KPiBhc3NvY2lhdGVk IHdpdGggb25lIENTIGdyb3VwIChDU0cpIHdoZW5ldmVyIENTRyBpcyBjcmVhdGVkLA0KPiBSUyBp cyBmcmVlZA0KPiBmcm9tIENTRyB3aGVuIENTRyBpcyB0ZXJtaW5hdGVkIGFuZCBSUyBpcyByZS11 c2VkIGZvciBhbm90aGVyDQo+IENTRyBsYXRlci4NCj4gSGVyZSwgcGVyc2lzdGVudCBSUyBhbGxv Y2F0aW9uL2RlLWFsbG9jYXRpb24gaXMNCj4gaW1wbGVtZW50YXRpb24tZGVwZW5kZW50DQo+IGFu ZCB0aGUgcmVzb3VyY2Ugb3B0aW1pemF0aW9uIGlzIHBvc3NpYmxlIGJhc2VkIG9uIGltcGxlbWVu dGF0aW9uLg0KPg0KPiBJIGFncmVlIHRoYXQgcHJlLW5lZ290aWF0ZWQgcGVyc2lzdGVudCBSUyB3 b3JrcyBmb3IgZW5kLXBvaW50DQo+IHdoaWNoIGFjdHMNCj4gYXMgU1JDIGFuZCBtYXkgd29yayBm b3IgU1JDIHdpdGggZmV3ICgyLTUpIHNlc3Npb25zLg0KPg0KPiBQbGVhc2UgbGV0IG1lIGtub3cg eW91ciBvcGluaW9uIGhlcmUuDQo+DQo+IFRoYW5rcw0KPiBQYXJ0aGENCj4NCj4gVG9waWMgLSBQ cm90b2NvbCAoSGVucnkgTHVtIC8gTGVvbiBQb3J0bWFuKQ0KPiBkcmFmdC1wb3J0bWFuLXNpcHJl Yy1wcm90b2NvbC0wMg0KPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0NCj4gRHJhZnQ6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXBvcnRtYW4tc2lwcmVjLXByb3RvY29sLw0KPiBTbGlkZXM6IGh0dHA6Ly9rZW5yZWhvci5jb20v aWV0Zi9zaXByZWMvSUVURjc5LjEvU0lQUkVDJTIwUHJvdG9jb2wlMjAtDQo+ICUyMHZpcnR1YWwl MjBpbnRlcmltJTIwRGVjJTIwMTYlMjAyMDEwLnBkZg0KPg0KPiBTbGlkZSA0IChQZXJzaXN0ZW50 IHJlY29yZGluZyk6IExlb24gcG9pbnRlZCBvdXQgdGhhdCB0aGUNCj4gd2hvbGUgaWRlYSBvZg0K PiBwZXJzaXN0ZW50IHJlY29yZGluZyBpcyBub3QgdG8gc3BlbmQgdGltZSBuZWdvdGlhdGluZyBt LWxpbmVzDQo+IHdoZW4gYSBDUw0KPiBzdGFydHMgLSBzbyBoZSBwcmVmZXJzIHRoZSBzZWNvbmQg b3B0aW9uIG9uIHRoZSBzbGlkZS4gRm9yIFNSQ3MgdGhhdA0KPiBzdXBwb3J0IGEgbGFyZ2UgbnVt YmVyIG9mIHBhcmFsbGVsIENTcywgdGhlIFNSQyBjb3VsZCBwcmUtbmVnb3RpYXRlIGENCj4gbGFy Z2UgbnVtYmVyIG9mIG0tbGluZXMgKHBlcmhhcHMgYmFzZWQgb24gbGljZW5zaW5nKSwgcmF0aGVy IGxpa2UNCj4gcHJvdmlzaW9uaW5nIHRydW5rcy4gUGF1bCBmZWx0IHRoYXQgdGhlIG90aGVyIG9w dGlvbiBzaG91bGQNCj4gYmUga2VwdCBvcGVuDQo+IC0gYSBzbGlnaHQgZGVsYXkgaW4gbmVnb3Rp YXRpbmcgYSBuZXcgbS1saW5lIGNvdWxkIGJlIGhhbmRsZWQgYnkNCj4gdHJhbnNtaXR0aW5nIHRo ZSBkYXRhIHNsaWdodGx5IGRlbGF5ZWQsIHdpdGhvdXQgbG9zaW5nIGFueS4gSGVucnkgYWxzbw0K PiBtZW50aW9uZWQgdGhlIHBvc3NpYmlsaXR5IG9mIHRoZSBvZmZlci1hbnN3ZXIgZmFpbGluZy4g SXQgd2FzDQo+IHF1ZXN0aW9uZWQNCj4gd2hldGhlciB0aGVyZSBuZWVkcyB0byBiZSBzb21ldGhp bmcgaW4gdGhlIHByb3RvY29sIHRvIGluZGljYXRlIHRoZQ0KPiBkZWxheS4gVGhpcyBpc3N1ZSBz aG91bGQgYmUgYnJvdWdodCB0byB0aGUgbGlzdC4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2lwcmVjIG1haWxpbmcgbGlzdA0KPiBzaXBy ZWNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBy ZWMNCj4NCg== --_000_07465C1D981ABC41A344374066AE1A2C389F4A5B6BTLVMBX01nicec_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PEhUTUwgZGlyPWx0cj48SEVBRD48VElUTEU+UkU6IFBlcnNpc3RlbnQgUlMgc2Vzc2lvbiB3aXRo IGxhcmdlIHNldCBvZiBDUyBpbmZvPC9USVRMRT4KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBj aGFyc2V0PXVuaWNvZGUiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPgo8TUVUQSBuYW1lPUdFTkVS QVRPUiBjb250ZW50PSJNU0hUTUwgOC4wMC42MDAxLjE4OTI4Ij48L0hFQUQ+CjxCT0RZPjxmb250 IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4NClRoZXJlIHdhcyBubyBpbnRl bnQgdG8gbGltaXQgbnVtYmVyIG9mIG0tbGluZXMgcGVyIFJTLiBJdCBpcyBtb3JlIGltcGxlbWVu dGF0aW9uIGRlY2lzaW9uIHRvIGhhdmUgb25lIGdpYW50IFJTIG9yIG11bHRpcGxlIFJzIGJsb2Nr cy4gPGJyPjxicj5MZW9uPC9mb250Pjxicj4mbmJzcDs8YnI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8Zm9udCBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8Yj5Gcm9tPC9iPjogUGFydGhh c2FyYXRoaSBSIChwYXJ0cikgW21haWx0bzpwYXJ0ckBjaXNjby5jb21dDTxicj48Yj5TZW50PC9i PjogV2VkbmVzZGF5LCBKYW51YXJ5IDI2LCAyMDExIDExOjM0IEFNPGJyPjxiPlRvPC9iPjogRWx3 ZWxsLCBKb2huICZsdDtqb2huLmVsd2VsbEBzaWVtZW5zLWVudGVycHJpc2UuY29tJmd0Ozsgc2lw cmVjQGlldGYub3JnICZsdDtzaXByZWNAaWV0Zi5vcmcmZ3Q7OyBMZW9uIFBvcnRtYW47IEhlbnJ5 IEx1bSAmbHQ7SGVucnkuTHVtQGFsY2F0ZWwtbHVjZW50LmNvbSZndDsNPGJyPjxiPlN1YmplY3Q8 L2I+OiBSRTogUGVyc2lzdGVudCBSUyBzZXNzaW9uIHdpdGggbGFyZ2Ugc2V0IG9mIENTIGluZm8N PGJyPjwvZm9udD4mbmJzcDs8YnI+PC9kaXY+DQoKPERJViBkaXI9bHRyIGlkPWlkT1dBUmVwbHlU ZXh0ODEzNDA+CjxESVYgZGlyPWx0cj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9MiBmYWNlPUFy aWFsPkpvaG4sPC9GT05UPjwvRElWPgo8RElWIGRpcj1sdHI+PEZPTlQgc2l6ZT0yIGZhY2U9QXJp YWw+PC9GT05UPiZuYnNwOzwvRElWPgo8RElWIGRpcj1sdHI+PEZPTlQgc2l6ZT0yIGZhY2U9QXJp YWw+UGxlYXNlIHJlYWQgaW5saW5lLjwvRk9OVD48L0RJVj4KPERJViBkaXI9bHRyPjxGT05UIHNp emU9MiBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8L0RJVj4KPERJViBkaXI9bHRyPjxGT05UIHNp emU9MiBmYWNlPUFyaWFsPlRoYW5rczwvRk9OVD48L0RJVj4KPERJViBkaXI9bHRyPjxGT05UIHNp emU9MiBmYWNlPUFyaWFsPlBhcnRoYTwvRk9OVD48L0RJVj48L0RJVj4KPERJViBkaXI9bHRyPjxC Uj4KPEhSIHRhYkluZGV4PS0xPgo8Rk9OVCBzaXplPTIgZmFjZT1UYWhvbWE+PEI+RnJvbTo8L0I+ IEVsd2VsbCwgSm9obiBbbWFpbHRvOmpvaG4uZWx3ZWxsQHNpZW1lbnMtZW50ZXJwcmlzZS5jb21d PEJSPjxCPlNlbnQ6PC9CPiBXZWQgMS8yNi8yMDExIDEyOjU0IFBNPEJSPjxCPlRvOjwvQj4gUGFy dGhhc2FyYXRoaSBSIChwYXJ0cik7IHNpcHJlY0BpZXRmLm9yZzsgTGVvbiBQb3J0bWFuOyBIZW5y eSBMdW08QlI+PEI+U3ViamVjdDo8L0I+IFJFOiBQZXJzaXN0ZW50IFJTIHNlc3Npb24gd2l0aCBs YXJnZSBzZXQgb2YgQ1MgaW5mbzxCUj48L0ZPTlQ+PEJSPjwvRElWPgo8RElWPgo8UD48Rk9OVCBz aXplPTI+SSB0ZW5kIHRvIGFncmVlIHdpdGggUGFydGhhJ3MgY29uY2VybnMgb24gc2NhbGFiaWxp dHkuIFBlcmhhcHMgc2VwYXJhdGUgcGVyc2lzdGVudCBSU3Mgd291bGQgYmUgcHJlZmVyYWJsZSwg cmF0aGVyIHRoYW4gYSBzaW5nbGUgcGVyc2lzdGVudCBSUyB3aXRoIGEgbGFyZ2UvaHVnZSBudW1i ZXIgb2YgcHJlLWFsbG9jYXRlZCBtLWxpbmVzLiBBIHBlcnNpc3RlbnQgUlMgc3VwcG9ydGluZyBt b3JlIHRoYW4gMSBwYXJhbGxlbCBDUyBtaWdodCBiZSBmZWFzaWJsZSBmb3IgYSB2ZXJ5IHNtYWxs IG51bWJlciBvZiBDU3MsIGFzIG1pZ2h0IGJlIGVuY291bnRlcmVkIGF0IGEgdXNlcidzIGRldmlj ZSwgc28gaXQgbWlnaHQgYmUgd29ydGggcmV0YWluaW5nIHRoZSBjb25jZXB0LiBPciB3ZSBjb3Vs ZCBzYXkgdGhhdCBhbiBSUyBtdXN0IG5vdCBzdXBwb3J0IG1vcmUgdGhhbiBvbmUgcGFyYWxsZWwg Q1MsIHRoZXJlYnkgZm9yY2luZyBzZXBhcmF0ZSBSU3MgZm9yIHBhcmFsbGVsIENTcy48L0ZPTlQ+ PC9QPgo8UD48Rk9OVCBzaXplPTI+Jmx0O1BhcnRoYSZndDsgd2Ugd2lsbCBkaXNjdXNzIGFib3V0 IHRoaXMgc29sdXRpb24gYXBwcm9hY2gmbmJzcDtpbiBkZXRhaWwgZHVyaW5nIHRvZGF5J3MgbWVl dGluZyZuYnNwO2FuZCZuYnNwO3RyeSB0byBicmluZyB0aGUgY2xvc3VyZSZuYnNwOyZsdDsvUGFy dGhhJmd0OzxCUj48QlI+SSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgdGhlIG5lZWQgdG8gYnJp bmcgQ1MtR3JvdXAgaW50byB0aGUgc29sdXRpb24uIERpZmZlcmVudCBDU3MgZnJvbSB0aGUgc2Ft ZSBDUy1Hcm91cCBjb3VsZCB1c2UgdGhlIHNhbWUgUlMgb3IgZGlmZmVyZW50IFJTcyAtIGl0IHNo b3VsZG4ndCBtYXR0ZXIuPEJSPjwvRk9OVD48L1A+CjxQPjxGT05UIHNpemU9Mj4mbHQ7UGFydGhh Jmd0OyBTb3JyeSBpbiBjYXNlIEkgY29uZnVzZWQuIEFzIHlvdSBtZW50aW9uZWQsIHRoZXJlIGlz IG5vIHJlc3RyaWN0aW9uIHcuci50IHNpbmdsZSBDU0cgaW4gc2luZ2xlJm5ic3A7UlMgb3Igc2lu Z2xlIENTRyBpbiBtdWx0aXBsZSBSUyZuYnNwO2FuZCBpdCBkb2VzIG5vdCBtYXR0ZXIuIEkganVz dCBwcm92aWRlZCZuYnNwO3RoZSBleGFtcGxlIHdoZXJlaW4mbmJzcDtlYWNoIFJTIG1heSB1c2Ug c2FtZSBDU0cuICZsdDsvUGFydGhhJmd0OyZuYnNwOyZuYnNwOzwvRk9OVD48L1A+CjxQPjxGT05U IHNpemU9Mj5Kb2huIChhcyBpbmRpdmlkdWFsKTxCUj48QlI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxCUj4mZ3Q7IEZyb206IHNpcHJlYy1ib3VuY2VzQGlldGYub3JnPEJSPiZndDsg WzxBIGhyZWY9Im1haWx0bzpzaXByZWMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNpcHJlYy1i b3VuY2VzQGlldGYub3JnPC9BPl0gT24gQmVoYWxmIE9mIFBhcnRoYXNhcmF0aGkgUiAocGFydHIp PEJSPiZndDsgU2VudDogMjYgSmFudWFyeSAyMDExIDAxOjAzPEJSPiZndDsgVG86IHNpcHJlY0Bp ZXRmLm9yZzsgTGVvbiBQb3J0bWFuOyBIZW5yeSBMdW08QlI+Jmd0OyBTdWJqZWN0OiBbc2lwcmVj XSBQZXJzaXN0ZW50IFJTIHNlc3Npb24gd2l0aCBsYXJnZSBzZXQgb2YgQ1MgaW5mbzxCUj4mZ3Q7 PEJSPiZndDsgTGVvbi9IZW5yeSw8QlI+Jmd0OzxCUj4mZ3Q7IFRoZSBwcm9wb3NhbCBvZiBwcmUt bmVnb3RpYXRlIGxhcmdlIG9mIG0tbGluZXMgaW4gY2FzZSBTUkMgc3VwcG9ydHM8QlI+Jmd0OyBs YXJnZSBudW1iZXIgb2Ygc2Vzc2lvbnMgaXMgbm90IGEgb3B0aW1hbCBzb2x1dGlvbiBmb3IgdGhl IGZvbGxvd2luZzxCUj4mZ3Q7IHJlYXNvbjo8QlI+Jmd0OzxCUj4mZ3Q7IDEpIE1haW50YWluaW5n IHN1Y2ggYSBsYXJnZSBudW1iZXIgb2YgbS1saW5lIHdpbGwgYmUgYW4gYXJjaGl0ZWN0dXJlPEJS PiZndDsgY2hhbGxlbmdlIGluIGFzIFNSQyB3b3VsZCBoYXZlIG1haW50YWluZWQgdmVyeSBmZXcg bS1saW5lPEJSPiZndDsgdGlsbCByZWNvcmRpbmc8QlI+Jmd0OyBmZWF0dXJlIGlzIGltcGxlbWVu dGVkLiBMZXQgdGFrZSZuYnNwOyAyMDAgc2Vzc2lvbiBzdXBwb3J0ZWQgaW48QlI+Jmd0OyBTUkMg dGhlbiA0MDA8QlI+Jmd0OyBtLWxpbmVzIGhhcyB0byBiZSBtYWludGFpbmVkIGluIGNhc2Ugb2Yg dW5taXhlZCByZWNvcmRpbmcgb2YgYXVkaW8gZm9yPEJSPiZndDsgdHdvIHBhcnR5IGNhbGwgYW5k IDgwMCBtLWxpbmVzIGluIGNhc2Ugb2YgcmVjb3JkaW5nIHVubWl4ZWQgYXVkaW8gJmFtcDs8QlI+ Jmd0OyB2aWRlbyBjYWxsIGZvciB0d28gcGFydHkgY2FsbC48QlI+Jmd0OzxCUj4mZ3Q7IDIpIEFz IEpvaG4gcG9pbnRlZCBvdXQgaW4gYW5vdGhlciBtYWlsIHRocmVhZCwgaXQgaXMgbm90IHBvc3Np YmxlIHRvPEJSPiZndDsgcmVtb3ZlIG0tbGluZSBvbmNlIGl0IGlzIGNyZWF0ZWQgaW4gcGVyc2lz dGVudCBSUy48QlI+Jmd0OzxCUj4mZ3Q7IDMpIFNSQyB3YXN0ZXMgaXRzIHJlc291cmNlcyB3aGVu IHRoZSBudW1iZXIgb2YgcmVjb3JkaW5nIHNlc3Npb24gaXM8QlI+Jmd0OyBsb3dlci4gSW4gY2Fz ZSBTUkMgcGVyZm9ybXMgbG90IG1vcmUgc2VydmljZXMgYXBhcnQgZnJvbTxCUj4mZ3Q7IHJlY29y ZGluZywgaHVnZTxCUj4mZ3Q7IHBlcmZvcm1hbmNlIGltcGFjdCB3aWxsIGJlIHNlZW4gaW4gU1JD IGFzIHRoZSByZXNvdXJjZXMgYXJlPEJSPiZndDsgcHJlLW9jY3VwaWVkPEJSPiZndDsgZm9yIHBl cnNpc3RlbnQgUlMuPEJSPiZndDs8QlI+Jmd0OyBJbiB0aGUgZWFybGllciBtYWlsLCBJIGhhdmUg cHJvcG9zZWQgdG8gY3JlYXRlIHByZS1hbGxvY2F0ZWQgcG9vbCBvZjxCUj4mZ3Q7IHBlcnNpc3Rl bnQgUlMgZm9yIFNSQyB3aGljaCBoYW5kbGUgbGFyZ2UgbnVtYmVyIHNlc3Npb25zLiBFYWNoIFJT IGlzPEJSPiZndDsgYXNzb2NpYXRlZCB3aXRoIG9uZSBDUyBncm91cCAoQ1NHKSB3aGVuZXZlciBD U0cgaXMgY3JlYXRlZCw8QlI+Jmd0OyBSUyBpcyBmcmVlZDxCUj4mZ3Q7IGZyb20gQ1NHIHdoZW4g Q1NHIGlzIHRlcm1pbmF0ZWQgYW5kIFJTIGlzIHJlLXVzZWQgZm9yIGFub3RoZXI8QlI+Jmd0OyBD U0cgbGF0ZXIuPEJSPiZndDsgSGVyZSwgcGVyc2lzdGVudCBSUyBhbGxvY2F0aW9uL2RlLWFsbG9j YXRpb24gaXM8QlI+Jmd0OyBpbXBsZW1lbnRhdGlvbi1kZXBlbmRlbnQ8QlI+Jmd0OyBhbmQgdGhl IHJlc291cmNlIG9wdGltaXphdGlvbiBpcyBwb3NzaWJsZSBiYXNlZCBvbiBpbXBsZW1lbnRhdGlv bi4mbmJzcDs8QlI+Jmd0OzxCUj4mZ3Q7IEkgYWdyZWUgdGhhdCBwcmUtbmVnb3RpYXRlZCBwZXJz aXN0ZW50IFJTIHdvcmtzIGZvciBlbmQtcG9pbnQ8QlI+Jmd0OyB3aGljaCBhY3RzPEJSPiZndDsg YXMgU1JDIGFuZCBtYXkgd29yayBmb3IgU1JDIHdpdGggZmV3ICgyLTUpIHNlc3Npb25zLjxCUj4m Z3Q7PEJSPiZndDsgUGxlYXNlIGxldCBtZSBrbm93IHlvdXIgb3BpbmlvbiBoZXJlLjxCUj4mZ3Q7 PEJSPiZndDsgVGhhbmtzPEJSPiZndDsgUGFydGhhPEJSPiZndDs8QlI+Jmd0OyBUb3BpYyAtIFBy b3RvY29sIChIZW5yeSBMdW0gLyBMZW9uIFBvcnRtYW4pPEJSPiZndDsgZHJhZnQtcG9ydG1hbi1z aXByZWMtcHJvdG9jb2wtMDI8QlI+Jmd0OyA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT08QlI+Jmd0OyBEcmFmdDogPEEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcG9ydG1hbi1zaXByZWMtcHJvdG9jb2wvIj5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wb3J0bWFuLXNpcHJlYy1wcm90b2NvbC88 L0E+PEJSPiZndDsgU2xpZGVzOiA8QSBocmVmPSJodHRwOi8va2VucmVob3IuY29tL2lldGYvc2lw cmVjL0lFVEY3OS4xL1NJUFJFQyUyMFByb3RvY29sJTIwLSI+aHR0cDovL2tlbnJlaG9yLmNvbS9p ZXRmL3NpcHJlYy9JRVRGNzkuMS9TSVBSRUMlMjBQcm90b2NvbCUyMC08L0E+PEJSPiZndDsgJTIw dmlydHVhbCUyMGludGVyaW0lMjBEZWMlMjAxNiUyMDIwMTAucGRmPEJSPiZndDs8QlI+Jmd0OyBT bGlkZSA0IChQZXJzaXN0ZW50IHJlY29yZGluZyk6IExlb24gcG9pbnRlZCBvdXQgdGhhdCB0aGU8 QlI+Jmd0OyB3aG9sZSBpZGVhIG9mPEJSPiZndDsgcGVyc2lzdGVudCByZWNvcmRpbmcgaXMgbm90 IHRvIHNwZW5kIHRpbWUgbmVnb3RpYXRpbmcgbS1saW5lczxCUj4mZ3Q7IHdoZW4gYSBDUzxCUj4m Z3Q7IHN0YXJ0cyAtIHNvIGhlIHByZWZlcnMgdGhlIHNlY29uZCBvcHRpb24gb24gdGhlIHNsaWRl LiBGb3IgU1JDcyB0aGF0PEJSPiZndDsgc3VwcG9ydCBhIGxhcmdlIG51bWJlciBvZiBwYXJhbGxl bCBDU3MsIHRoZSBTUkMgY291bGQgcHJlLW5lZ290aWF0ZSBhPEJSPiZndDsgbGFyZ2UgbnVtYmVy IG9mIG0tbGluZXMgKHBlcmhhcHMgYmFzZWQgb24gbGljZW5zaW5nKSwgcmF0aGVyIGxpa2U8QlI+ Jmd0OyBwcm92aXNpb25pbmcgdHJ1bmtzLiBQYXVsIGZlbHQgdGhhdCB0aGUgb3RoZXIgb3B0aW9u IHNob3VsZDxCUj4mZ3Q7IGJlIGtlcHQgb3BlbjxCUj4mZ3Q7IC0gYSBzbGlnaHQgZGVsYXkgaW4g bmVnb3RpYXRpbmcgYSBuZXcgbS1saW5lIGNvdWxkIGJlIGhhbmRsZWQgYnk8QlI+Jmd0OyB0cmFu c21pdHRpbmcgdGhlIGRhdGEgc2xpZ2h0bHkgZGVsYXllZCwgd2l0aG91dCBsb3NpbmcgYW55LiBI ZW5yeSBhbHNvPEJSPiZndDsgbWVudGlvbmVkIHRoZSBwb3NzaWJpbGl0eSBvZiB0aGUgb2ZmZXIt YW5zd2VyIGZhaWxpbmcuIEl0IHdhczxCUj4mZ3Q7IHF1ZXN0aW9uZWQ8QlI+Jmd0OyB3aGV0aGVy IHRoZXJlIG5lZWRzIHRvIGJlIHNvbWV0aGluZyBpbiB0aGUgcHJvdG9jb2wgdG8gaW5kaWNhdGUg dGhlPEJSPiZndDsgZGVsYXkuIFRoaXMgaXNzdWUgc2hvdWxkIGJlIGJyb3VnaHQgdG8gdGhlIGxp c3QuPEJSPiZndDs8QlI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxCUj4mZ3Q7IHNpcHJlYyBtYWlsaW5nIGxpc3Q8QlI+Jmd0OyBzaXByZWNAaWV0 Zi5vcmc8QlI+Jmd0OyA8QSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NpcHJlYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXByZWM8 L0E+PEJSPiZndDs8QlI+PC9QPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg== --_000_07465C1D981ABC41A344374066AE1A2C389F4A5B6BTLVMBX01nicec_-- From john.elwell@siemens-enterprise.com Wed Jan 26 05:23:36 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1AAB3A69B3 for ; Wed, 26 Jan 2011 05:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaRty--9KSjL for ; Wed, 26 Jan 2011 05:23:35 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 016BA3A63C9 for ; Wed, 26 Jan 2011 05:23:34 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3149830; Wed, 26 Jan 2011 14:26:34 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 75A831EB82AB; Wed, 26 Jan 2011 14:26:34 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 26 Jan 2011 14:26:34 +0100 From: "Elwell, John" To: Leon Portman , "'partr@cisco.com'" , "'siprec@ietf.org'" , "'Henry.Lum@alcatel-lucent.com'" Date: Wed, 26 Jan 2011 14:26:33 +0100 Thread-Topic: Persistent RS session with large set of CS info Thread-Index: Acu83pcEUtR/mjUXQMit9DldGQtWeQAD1xmgAA7KipAABHZ9mAAGtQ0eAAGOdHA= Message-ID: References: <07465C1D981ABC41A344374066AE1A2C389F4A5B6B@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C389F4A5B6B@TLVMBX01.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Persistent RS session with large set of CS info X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 13:23:36 -0000 That is a decision we need to make - we would just need to consider the imp= lications. For example, as soon as you allow >1 parallel CS on the same RS,= you have to decide how to distinguish their metadatas, e.g., multiple body= parts, multiple elements in the same XML body part. Not really a problem, = just need to figure it out. John (as individual) > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com]=20 > Sent: 26 January 2011 12:37 > To: 'partr@cisco.com'; Elwell, John; 'siprec@ietf.org';=20 > 'Henry.Lum@alcatel-lucent.com' > Subject: Re: Persistent RS session with large set of CS info >=20 > There was no intent to limit number of m-lines per RS. It is=20 > more implementation decision to have one giant RS or multiple=20 > Rs blocks.=20 >=20 > Leon > =20 >=20 > From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 > Sent: Wednesday, January 26, 2011 11:34 AM > To: Elwell, John ;=20 > siprec@ietf.org ; Leon Portman; Henry Lum=20 > =20 > Subject: RE: Persistent RS session with large set of CS info=20 > =20 >=20 > John, > =20 > Please read inline. > =20 > Thanks > Partha >=20 > ________________________________ >=20 > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Wed 1/26/2011 12:54 PM > To: Parthasarathi R (partr); siprec@ietf.org; Leon Portman; Henry Lum > Subject: RE: Persistent RS session with large set of CS info >=20 >=20 >=20 > I tend to agree with Partha's concerns on scalability.=20 > Perhaps separate persistent RSs would be preferable, rather=20 > than a single persistent RS with a large/huge number of=20 > pre-allocated m-lines. A persistent RS supporting more than 1=20 > parallel CS might be feasible for a very small number of CSs,=20 > as might be encountered at a user's device, so it might be=20 > worth retaining the concept. Or we could say that an RS must=20 > not support more than one parallel CS, thereby forcing=20 > separate RSs for parallel CSs. >=20 > we will discuss about this solution approach in=20 > detail during today's meeting and try to bring the closure >=20 > I am not sure I understand the need to bring CS-Group into=20 > the solution. Different CSs from the same CS-Group could use=20 > the same RS or different RSs - it shouldn't matter. >=20 >=20 > Sorry in case I confused. As you mentioned, there is=20 > no restriction w.r.t single CSG in single RS or single CSG in=20 > multiple RS and it does not matter. I just provided the=20 > example wherein each RS may use same CSG. =20 >=20 > John (as individual) >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi=20 > R (partr) > > Sent: 26 January 2011 01:03 > > To: siprec@ietf.org; Leon Portman; Henry Lum > > Subject: [siprec] Persistent RS session with large set of CS info > > > > Leon/Henry, > > > > The proposal of pre-negotiate large of m-lines in case SRC supports > > large number of sessions is not a optimal solution for the following > > reason: > > > > 1) Maintaining such a large number of m-line will be an architecture > > challenge in as SRC would have maintained very few m-line > > till recording > > feature is implemented. Let take 200 session supported in > > SRC then 400 > > m-lines has to be maintained in case of unmixed recording=20 > of audio for > > two party call and 800 m-lines in case of recording unmixed audio & > > video call for two party call. > > > > 2) As John pointed out in another mail thread, it is not possible to > > remove m-line once it is created in persistent RS. > > > > 3) SRC wastes its resources when the number of recording session is > > lower. In case SRC performs lot more services apart from > > recording, huge > > performance impact will be seen in SRC as the resources are > > pre-occupied > > for persistent RS. > > > > In the earlier mail, I have proposed to create pre-allocated pool of > > persistent RS for SRC which handle large number sessions. Each RS is > > associated with one CS group (CSG) whenever CSG is created, > > RS is freed > > from CSG when CSG is terminated and RS is re-used for another > > CSG later. > > Here, persistent RS allocation/de-allocation is > > implementation-dependent > > and the resource optimization is possible based on implementation.=20 > > > > I agree that pre-negotiated persistent RS works for end-point > > which acts > > as SRC and may work for SRC with few (2-5) sessions. > > > > Please let me know your opinion here. > > > > Thanks > > Partha > > > > Topic - Protocol (Henry Lum / Leon Portman) > > draft-portman-siprec-protocol-02 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Draft:=20 > https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ > > Slides:=20 > http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20- > > %20virtual%20interim%20Dec%2016%202010.pdf > > > > Slide 4 (Persistent recording): Leon pointed out that the > > whole idea of > > persistent recording is not to spend time negotiating m-lines > > when a CS > > starts - so he prefers the second option on the slide. For SRCs that > > support a large number of parallel CSs, the SRC could=20 > pre-negotiate a > > large number of m-lines (perhaps based on licensing), rather like > > provisioning trunks. Paul felt that the other option should > > be kept open > > - a slight delay in negotiating a new m-line could be handled by > > transmitting the data slightly delayed, without losing any.=20 > Henry also > > mentioned the possibility of the offer-answer failing. It was > > questioned > > whether there needs to be something in the protocol to indicate the > > delay. This issue should be brought to the list. > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > >=20 >=20 > = From rmohanr@cisco.com Wed Jan 26 05:36:16 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19D8F3A69C6 for ; Wed, 26 Jan 2011 05:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8FWBYAJl3P0 for ; Wed, 26 Jan 2011 05:36:15 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id F39573A69C2 for ; Wed, 26 Jan 2011 05:36:14 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADuzP01AaMHG/2dsb2JhbACkdnOgW5tOhU8EhRWKYA Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-5.cisco.com with ESMTP; 26 Jan 2011 13:39:14 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0QDdC25017360; Wed, 26 Jan 2011 13:39:14 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Jan 2011 19:09:11 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Jan 2011 19:09:08 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD05124D27@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] revised REQ-010 Thread-Index: Acu9J5IVPCoXGIduQ0K4HgOna9O+vwAAp4FQAA0MJsA= References: <7744FE52C78D944587F03773EB4514610950F6A3@xmb-sjc-22e.amer.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , "Ken Rehor (krehor)" , X-OriginalArrivalTime: 26 Jan 2011 13:39:11.0835 (UTC) FILETIME=[6A4F52B0:01CBBD5E] Subject: Re: [siprec] revised REQ-010 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 13:36:16 -0000 +1 Look good to me too Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Wednesday, January 26, 2011 12:56 PM > To: Ken Rehor (krehor); siprec@ietf.org > Subject: Re: [siprec] revised REQ-010 >=20 > WFM >=20 > John >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Ken Rehor (krehor) > > Sent: 26 January 2011 07:07 > > To: siprec@ietf.org > > Subject: [siprec] revised REQ-010 > > > > > > > > The following is a proposal to change REQ-010. The existing > > requirement is: > > > > > > > > o REQ-010 The mechanism MUST support the ability to deliver to the > > > > SRS multiple media streams for a given CS. > > > > > > > > The proposed new version is: > > > > > > > > o REQ-010 The mechanism MUST support the ability to deliver to the > > SRS multiple media streams of the same or different media > > types for a given CS. > > > > > > > > > > > > Ken > > > > > > > > > > > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From Leon.Portman@nice.com Wed Jan 26 05:42:17 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42CF43A69BE for ; Wed, 26 Jan 2011 05:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQmX7ie8P9Wr for ; Wed, 26 Jan 2011 05:42:16 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id DD6E83A69AE for ; Wed, 26 Jan 2011 05:42:15 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Wed, 26 Jan 2011 15:45:15 +0200 From: Leon Portman To: "Ram Mohan R (rmohanr)" , "Elwell, John" , "Ken Rehor (krehor)" , "siprec@ietf.org" Date: Wed, 26 Jan 2011 15:45:12 +0200 Thread-Topic: [siprec] revised REQ-010 Thread-Index: Acu9J5IVPCoXGIduQ0K4HgOna9O+vwAAp4FQAA0MJsAAADVrwA== Message-ID: <07465C1D981ABC41A344374066AE1A2C389F5D1A25@TLVMBX01.nice.com> References: <7744FE52C78D944587F03773EB4514610950F6A3@xmb-sjc-22e.amer.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05124D27@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD05124D27@XMB-BGL-417.cisco.com> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] revised REQ-010 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 13:42:17 -0000 +1 leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Ram Mohan R (rmohanr) Sent: Wednesday, January 26, 2011 3:39 PM To: Elwell, John; Ken Rehor (krehor); siprec@ietf.org Subject: Re: [siprec] revised REQ-010 +1 Look good to me too Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Elwell, John > Sent: Wednesday, January 26, 2011 12:56 PM > To: Ken Rehor (krehor); siprec@ietf.org > Subject: Re: [siprec] revised REQ-010 >=20 > WFM >=20 > John >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Ken Rehor (krehor) > > Sent: 26 January 2011 07:07 > > To: siprec@ietf.org > > Subject: [siprec] revised REQ-010 > > > > > > > > The following is a proposal to change REQ-010. The existing=20 > > requirement is: > > > > > > > > o REQ-010 The mechanism MUST support the ability to deliver to the > > > > SRS multiple media streams for a given CS. > > > > > > > > The proposed new version is: > > > > > > > > o REQ-010 The mechanism MUST support the ability to deliver to the > > SRS multiple media streams of the same or different media types=20 > > for a given CS. > > > > > > > > > > > > Ken > > > > > > > > > > > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > > > > > _______________________________________________ > 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 From rmohanr@cisco.com Wed Jan 26 05:49:32 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBDD23A69C4 for ; Wed, 26 Jan 2011 05:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.185 X-Spam-Level: X-Spam-Status: No, score=-10.185 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epLgvhI89Q+u for ; Wed, 26 Jan 2011 05:49:31 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id A095A28C0D0 for ; Wed, 26 Jan 2011 05:49:30 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgEAM+1P02Q/khNgWdsb2JhbACkdhUBARYiJKBnm06FTwSFFYpg Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 26 Jan 2011 13:52:30 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p0QDqTS4008991; Wed, 26 Jan 2011 13:52:30 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Jan 2011 19:22:29 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Jan 2011 19:22:25 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD05124D2C@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Persistent RS session with large set of CS info Thread-Index: Acu83pcEUtR/mjUXQMit9DldGQtWeQAD1xmgAA7KipAABHZ9mAAGtQ0eAAGOdHAAAKTQAA== References: <07465C1D981ABC41A344374066AE1A2C389F4A5B6B@TLVMBX01.nice.com> From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , "Leon Portman" , "Parthasarathi R (partr)" , , X-OriginalArrivalTime: 26 Jan 2011 13:52:29.0289 (UTC) FILETIME=[45A12590:01CBBD60] Subject: Re: [siprec] Persistent RS session with large set of CS info X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 13:49:32 -0000 My thoughts on this: The metadata model and the format allows multiple CS [ any number of them] within a single RS. The proposed XML schema of metadata can accommodate multiple sessions(each with its XML part) and has the mechanism to distinguish them. I do agree that in case we have several CSs [ hundreds on them] the XML would be huge and we will have to look for ways to compress the XML body ( which in my opinion should be outside the scope). IMO that is purely implementation specific[ depending on how much each SRC can scale to and also depends on the MTU of that network]. As such we should not restrict the number of CSs per RS. Probably we should have some guidelines. Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Wednesday, January 26, 2011 6:57 PM > To: Leon Portman; Parthasarathi R (partr); 'siprec@ietf.org'; > 'Henry.Lum@alcatel-lucent.com' > Subject: Re: [siprec] Persistent RS session with large set of CS info >=20 > That is a decision we need to make - we would just need to consider the > implications. For example, as soon as you allow >1 parallel CS on the > same RS, you have to decide how to distinguish their metadatas, e.g., > multiple body parts, multiple elements in the same XML body part. Not > really a problem, just need to figure it out. >=20 > John (as individual) >=20 > > -----Original Message----- > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > Sent: 26 January 2011 12:37 > > To: 'partr@cisco.com'; Elwell, John; 'siprec@ietf.org'; > > 'Henry.Lum@alcatel-lucent.com' > > Subject: Re: Persistent RS session with large set of CS info > > > > There was no intent to limit number of m-lines per RS. It is > > more implementation decision to have one giant RS or multiple > > Rs blocks. > > > > Leon > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: Wednesday, January 26, 2011 11:34 AM > > To: Elwell, John ; > > siprec@ietf.org ; Leon Portman; Henry Lum > > > > Subject: RE: Persistent RS session with large set of CS info > > > > > > John, > > > > Please read inline. > > > > Thanks > > Partha > > > > ________________________________ > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Wed 1/26/2011 12:54 PM > > To: Parthasarathi R (partr); siprec@ietf.org; Leon Portman; Henry Lum > > Subject: RE: Persistent RS session with large set of CS info > > > > > > > > I tend to agree with Partha's concerns on scalability. > > Perhaps separate persistent RSs would be preferable, rather > > than a single persistent RS with a large/huge number of > > pre-allocated m-lines. A persistent RS supporting more than 1 > > parallel CS might be feasible for a very small number of CSs, > > as might be encountered at a user's device, so it might be > > worth retaining the concept. Or we could say that an RS must > > not support more than one parallel CS, thereby forcing > > separate RSs for parallel CSs. > > > > we will discuss about this solution approach in > > detail during today's meeting and try to bring the closure > > > > I am not sure I understand the need to bring CS-Group into > > the solution. Different CSs from the same CS-Group could use > > the same RS or different RSs - it shouldn't matter. > > > > > > Sorry in case I confused. As you mentioned, there is > > no restriction w.r.t single CSG in single RS or single CSG in > > multiple RS and it does not matter. I just provided the > > example wherein each RS may use same CSG. > > > > John (as individual) > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi > > R (partr) > > > Sent: 26 January 2011 01:03 > > > To: siprec@ietf.org; Leon Portman; Henry Lum > > > Subject: [siprec] Persistent RS session with large set of CS info > > > > > > Leon/Henry, > > > > > > The proposal of pre-negotiate large of m-lines in case SRC supports > > > large number of sessions is not a optimal solution for the > following > > > reason: > > > > > > 1) Maintaining such a large number of m-line will be an > architecture > > > challenge in as SRC would have maintained very few m-line > > > till recording > > > feature is implemented. Let take 200 session supported in > > > SRC then 400 > > > m-lines has to be maintained in case of unmixed recording > > of audio for > > > two party call and 800 m-lines in case of recording unmixed audio & > > > video call for two party call. > > > > > > 2) As John pointed out in another mail thread, it is not possible > to > > > remove m-line once it is created in persistent RS. > > > > > > 3) SRC wastes its resources when the number of recording session is > > > lower. In case SRC performs lot more services apart from > > > recording, huge > > > performance impact will be seen in SRC as the resources are > > > pre-occupied > > > for persistent RS. > > > > > > In the earlier mail, I have proposed to create pre-allocated pool > of > > > persistent RS for SRC which handle large number sessions. Each RS > is > > > associated with one CS group (CSG) whenever CSG is created, > > > RS is freed > > > from CSG when CSG is terminated and RS is re-used for another > > > CSG later. > > > Here, persistent RS allocation/de-allocation is > > > implementation-dependent > > > and the resource optimization is possible based on implementation. > > > > > > I agree that pre-negotiated persistent RS works for end-point > > > which acts > > > as SRC and may work for SRC with few (2-5) sessions. > > > > > > Please let me know your opinion here. > > > > > > Thanks > > > Partha > > > > > > Topic - Protocol (Henry Lum / Leon Portman) > > > draft-portman-siprec-protocol-02 > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > Draft: > > https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ > > > Slides: > > http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20- > > > %20virtual%20interim%20Dec%2016%202010.pdf > > > > > > Slide 4 (Persistent recording): Leon pointed out that the > > > whole idea of > > > persistent recording is not to spend time negotiating m-lines > > > when a CS > > > starts - so he prefers the second option on the slide. For SRCs > that > > > support a large number of parallel CSs, the SRC could > > pre-negotiate a > > > large number of m-lines (perhaps based on licensing), rather like > > > provisioning trunks. Paul felt that the other option should > > > be kept open > > > - a slight delay in negotiating a new m-line could be handled by > > > transmitting the data slightly delayed, without losing any. > > Henry also > > > mentioned the possibility of the offer-answer failing. It was > > > questioned > > > whether there needs to be something in the protocol to indicate the > > > delay. This issue should be brought to the list. > > > > > > _______________________________________________ > > > 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 From pkyzivat@cisco.com Wed Jan 26 07:05:16 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E05773A67E5 for ; Wed, 26 Jan 2011 07:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.494 X-Spam-Level: X-Spam-Status: No, score=-110.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOfIH93P-kQN for ; Wed, 26 Jan 2011 07:05:15 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A7A893A67D7 for ; Wed, 26 Jan 2011 07:05:14 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8DAOjHP02Q/khMgWdsb2JhbACkdxUBARYiJKEim0aFTwSFF4cSg0Y Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 26 Jan 2011 15:08:14 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p0QF8EFQ017620 for ; Wed, 26 Jan 2011 15:08:14 GMT Message-ID: <4D4038DE.5090707@cisco.com> Date: Wed, 26 Jan 2011 10:08:14 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: siprec@ietf.org References: <07465C1D981ABC41A344374066AE1A2C389F4A5B6B@TLVMBX01.nice.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Persistent RS session with large set of CS info X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 15:05:17 -0000 On 1/26/2011 8:26 AM, Elwell, John wrote: > That is a decision we need to make - we would just need to consider the implications. For example, as soon as you allow>1 parallel CS on the same RS, you have to decide how to distinguish their metadatas, e.g., multiple body parts, multiple elements in the same XML body part. Not really a problem, just need to figure it out. The metadata model currently reflects an assumption that you can have multiple CS and CS-Groups per RS. If there is some question about that, then please bring it up as an issue against the metadata model. Thanks, Paul > John (as individual) > >> -----Original Message----- >> From: Leon Portman [mailto:Leon.Portman@nice.com] >> Sent: 26 January 2011 12:37 >> To: 'partr@cisco.com'; Elwell, John; 'siprec@ietf.org'; >> 'Henry.Lum@alcatel-lucent.com' >> Subject: Re: Persistent RS session with large set of CS info >> >> There was no intent to limit number of m-lines per RS. It is >> more implementation decision to have one giant RS or multiple >> Rs blocks. >> >> Leon >> >> >> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >> Sent: Wednesday, January 26, 2011 11:34 AM >> To: Elwell, John; >> siprec@ietf.org; Leon Portman; Henry Lum >> >> Subject: RE: Persistent RS session with large set of CS info >> >> >> John, >> >> Please read inline. >> >> Thanks >> Partha >> >> ________________________________ >> >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> Sent: Wed 1/26/2011 12:54 PM >> To: Parthasarathi R (partr); siprec@ietf.org; Leon Portman; Henry Lum >> Subject: RE: Persistent RS session with large set of CS info >> >> >> >> I tend to agree with Partha's concerns on scalability. >> Perhaps separate persistent RSs would be preferable, rather >> than a single persistent RS with a large/huge number of >> pre-allocated m-lines. A persistent RS supporting more than 1 >> parallel CS might be feasible for a very small number of CSs, >> as might be encountered at a user's device, so it might be >> worth retaining the concept. Or we could say that an RS must >> not support more than one parallel CS, thereby forcing >> separate RSs for parallel CSs. >> >> we will discuss about this solution approach in >> detail during today's meeting and try to bring the closure >> >> I am not sure I understand the need to bring CS-Group into >> the solution. Different CSs from the same CS-Group could use >> the same RS or different RSs - it shouldn't matter. >> >> >> Sorry in case I confused. As you mentioned, there is >> no restriction w.r.t single CSG in single RS or single CSG in >> multiple RS and it does not matter. I just provided the >> example wherein each RS may use same CSG. >> >> John (as individual) >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi >> R (partr) >>> Sent: 26 January 2011 01:03 >>> To: siprec@ietf.org; Leon Portman; Henry Lum >>> Subject: [siprec] Persistent RS session with large set of CS info >>> >>> Leon/Henry, >>> >>> The proposal of pre-negotiate large of m-lines in case SRC supports >>> large number of sessions is not a optimal solution for the following >>> reason: >>> >>> 1) Maintaining such a large number of m-line will be an architecture >>> challenge in as SRC would have maintained very few m-line >>> till recording >>> feature is implemented. Let take 200 session supported in >>> SRC then 400 >>> m-lines has to be maintained in case of unmixed recording >> of audio for >>> two party call and 800 m-lines in case of recording unmixed audio& >>> video call for two party call. >>> >>> 2) As John pointed out in another mail thread, it is not possible to >>> remove m-line once it is created in persistent RS. >>> >>> 3) SRC wastes its resources when the number of recording session is >>> lower. In case SRC performs lot more services apart from >>> recording, huge >>> performance impact will be seen in SRC as the resources are >>> pre-occupied >>> for persistent RS. >>> >>> In the earlier mail, I have proposed to create pre-allocated pool of >>> persistent RS for SRC which handle large number sessions. Each RS is >>> associated with one CS group (CSG) whenever CSG is created, >>> RS is freed >>> from CSG when CSG is terminated and RS is re-used for another >>> CSG later. >>> Here, persistent RS allocation/de-allocation is >>> implementation-dependent >>> and the resource optimization is possible based on implementation. >>> >>> I agree that pre-negotiated persistent RS works for end-point >>> which acts >>> as SRC and may work for SRC with few (2-5) sessions. >>> >>> Please let me know your opinion here. >>> >>> Thanks >>> Partha >>> >>> Topic - Protocol (Henry Lum / Leon Portman) >>> draft-portman-siprec-protocol-02 >>> ================================================ >>> Draft: >> https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ >>> Slides: >> http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20- >>> %20virtual%20interim%20Dec%2016%202010.pdf >>> >>> Slide 4 (Persistent recording): Leon pointed out that the >>> whole idea of >>> persistent recording is not to spend time negotiating m-lines >>> when a CS >>> starts - so he prefers the second option on the slide. For SRCs that >>> support a large number of parallel CSs, the SRC could >> pre-negotiate a >>> large number of m-lines (perhaps based on licensing), rather like >>> provisioning trunks. Paul felt that the other option should >>> be kept open >>> - a slight delay in negotiating a new m-line could be handled by >>> transmitting the data slightly delayed, without losing any. >> Henry also >>> mentioned the possibility of the offer-answer failing. It was >>> questioned >>> whether there needs to be something in the protocol to indicate the >>> delay. This issue should be brought to the list. >>> >>> _______________________________________________ >>> 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 > From eckelcu@cisco.com Wed Jan 26 07:30:37 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 554403A67F0 for ; Wed, 26 Jan 2011 07:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.294 X-Spam-Level: X-Spam-Status: No, score=-10.294 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hE3TherWDxu5 for ; Wed, 26 Jan 2011 07:30:36 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 344843A67A5 for ; Wed, 26 Jan 2011 07:30:36 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAALNP02rRN+K/2dsb2JhbACkd3OhGptEhU8EhReKXg Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 26 Jan 2011 15:33:37 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p0QFXbsT001920; Wed, 26 Jan 2011 15:33:37 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Jan 2011 07:33:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Jan 2011 07:33:35 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] revised REQ-010 Thread-Index: Acu9J5IVPCoXGIduQ0K4HgOna9O+vwAAp4FQABELRSA= References: <7744FE52C78D944587F03773EB4514610950F6A3@xmb-sjc-22e.amer.cisco.com> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , "Ken Rehor (krehor)" , X-OriginalArrivalTime: 26 Jan 2011 15:33:37.0087 (UTC) FILETIME=[6651A4F0:01CBBD6E] Subject: Re: [siprec] revised REQ-010 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 15:30:37 -0000 +1 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Tuesday, January 25, 2011 11:26 PM > To: Ken Rehor (krehor); siprec@ietf.org > Subject: Re: [siprec] revised REQ-010 >=20 > WFM >=20 > John >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Ken Rehor (krehor) > > Sent: 26 January 2011 07:07 > > To: siprec@ietf.org > > Subject: [siprec] revised REQ-010 > > > > > > > > The following is a proposal to change REQ-010. The existing > > requirement is: > > > > > > > > o REQ-010 The mechanism MUST support the ability to deliver to the > > > > SRS multiple media streams for a given CS. > > > > > > > > The proposed new version is: > > > > > > > > o REQ-010 The mechanism MUST support the ability to deliver to the > > SRS multiple media streams of the same or different media > > types for a given CS. > > > > > > > > > > > > Ken > > > > > > > > > > > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From Henry.Lum@alcatel-lucent.com Wed Jan 26 07:46:32 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0358A3A6864 for ; Wed, 26 Jan 2011 07:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.138 X-Spam-Level: X-Spam-Status: No, score=-6.138 tagged_above=-999 required=5 tests=[AWL=0.461, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZ-Ij61RirQQ for ; Wed, 26 Jan 2011 07:46:30 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id BF5173A67F6 for ; Wed, 26 Jan 2011 07:46:30 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p0QFnUNx019287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Jan 2011 09:49:30 -0600 (CST) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [172.22.70.114]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0QFnSq9031066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Jan 2011 09:49:29 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.wc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id p0QFnS9w024704; Wed, 26 Jan 2011 07:49:28 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Jan 2011 07:49:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Jan 2011 07:49:25 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF7406989D66@NAHALD.us.int.genesyslab.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] revised REQ-010 Thread-Index: Acu9J5IVPCoXGIduQ0K4HgOna9O+vwAAp4FQABGaJ2A= References: <7744FE52C78D944587F03773EB4514610950F6A3@xmb-sjc-22e.amer.cisco.com> From: "Henry Lum" To: "Elwell, John" , "Ken Rehor (krehor)" , X-OriginalArrivalTime: 26 Jan 2011 15:49:27.0223 (UTC) FILETIME=[9CA4E470:01CBBD70] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [siprec] revised REQ-010 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 15:46:32 -0000 +1 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Wednesday, January 26, 2011 2:26 AM > To: Ken Rehor (krehor); siprec@ietf.org > Subject: Re: [siprec] revised REQ-010 >=20 > WFM >=20 > John >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Ken Rehor (krehor) > > Sent: 26 January 2011 07:07 > > To: siprec@ietf.org > > Subject: [siprec] revised REQ-010 > > > > > > > > The following is a proposal to change REQ-010. The existing > > requirement is: > > > > > > > > o REQ-010 The mechanism MUST support the ability to deliver to the > > > > SRS multiple media streams for a given CS. > > > > > > > > The proposed new version is: > > > > > > > > o REQ-010 The mechanism MUST support the ability to deliver to the > > SRS multiple media streams of the same or different media > > types for a given CS. > > > > > > > > > > > > Ken > > > > > > > > > > > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From john.elwell@siemens-enterprise.com Wed Jan 26 07:57:42 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE9243A6768 for ; Wed, 26 Jan 2011 07:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.235 X-Spam-Level: X-Spam-Status: No, score=-102.235 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URVyMfE62D9b for ; Wed, 26 Jan 2011 07:57:41 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id E12D43A66B4 for ; Wed, 26 Jan 2011 07:57:40 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3153044; Wed, 26 Jan 2011 17:00:40 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 8BB9D1EB82AE; Wed, 26 Jan 2011 17:00:40 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 26 Jan 2011 17:00:40 +0100 From: "Elwell, John" To: "Ram Mohan R (rmohanr)" , Leon Portman , "Parthasarathi R (partr)" , "siprec@ietf.org" , "Henry.Lum@alcatel-lucent.com" Date: Wed, 26 Jan 2011 17:00:38 +0100 Thread-Topic: [siprec] Persistent RS session with large set of CS info Thread-Index: Acu83pcEUtR/mjUXQMit9DldGQtWeQAD1xmgAA7KipAABHZ9mAAGtQ0eAAGOdHAAAKTQAAAEzJ/w Message-ID: References: <07465C1D981ABC41A344374066AE1A2C389F4A5B6B@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD05124D2C@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD05124D2C@XMB-BGL-417.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Persistent RS session with large set of CS info X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 15:57:42 -0000 Ram, Yes, I tend to agree about not restricting the number of CSs per RS on the = basis of metadata size, particularly in the light of discussions on the cal= l about sending partial metadata. I think other considerations will deter t= he use of a single RS for a huge number of parallel CSs - I am thinking of = the number of m-lines in the SDP and the fact that this is only allowed to = increase and can never decrease. John (as individual)=20 > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 > Sent: 26 January 2011 13:52 > To: Elwell, John; Leon Portman; Parthasarathi R (partr);=20 > siprec@ietf.org; Henry.Lum@alcatel-lucent.com > Subject: RE: [siprec] Persistent RS session with large set of CS info >=20 > My thoughts on this: >=20 > The metadata model and the format allows multiple CS [ any number of > them] within a single RS. The proposed XML schema of metadata can > accommodate multiple sessions(each with its XML part) and has the > mechanism to distinguish them. >=20 > I do agree that in case we have several CSs [ hundreds on=20 > them] the XML > would be huge and we will have to look for ways to compress=20 > the XML body > ( which in my opinion should be outside the scope). IMO that is purely > implementation specific[ depending on how much each SRC can scale to > and also depends on the MTU of that network]. >=20 > As such we should not restrict the number of CSs per RS. Probably we > should have some guidelines. >=20 > Ram >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > > Sent: Wednesday, January 26, 2011 6:57 PM > > To: Leon Portman; Parthasarathi R (partr); 'siprec@ietf.org'; > > 'Henry.Lum@alcatel-lucent.com' > > Subject: Re: [siprec] Persistent RS session with large set=20 > of CS info > >=20 > > That is a decision we need to make - we would just need to consider > the > > implications. For example, as soon as you allow >1 parallel=20 > CS on the > > same RS, you have to decide how to distinguish their=20 > metadatas, e.g., > > multiple body parts, multiple elements in the same XML body=20 > part. Not > > really a problem, just need to figure it out. > >=20 > > John (as individual) > >=20 > > > -----Original Message----- > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > Sent: 26 January 2011 12:37 > > > To: 'partr@cisco.com'; Elwell, John; 'siprec@ietf.org'; > > > 'Henry.Lum@alcatel-lucent.com' > > > Subject: Re: Persistent RS session with large set of CS info > > > > > > There was no intent to limit number of m-lines per RS. It is > > > more implementation decision to have one giant RS or multiple > > > Rs blocks. > > > > > > Leon > > > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > Sent: Wednesday, January 26, 2011 11:34 AM > > > To: Elwell, John ; > > > siprec@ietf.org ; Leon Portman; Henry Lum > > > > > > Subject: RE: Persistent RS session with large set of CS info > > > > > > > > > John, > > > > > > Please read inline. > > > > > > Thanks > > > Partha > > > > > > ________________________________ > > > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Wed 1/26/2011 12:54 PM > > > To: Parthasarathi R (partr); siprec@ietf.org; Leon Portman; Henry > Lum > > > Subject: RE: Persistent RS session with large set of CS info > > > > > > > > > > > > I tend to agree with Partha's concerns on scalability. > > > Perhaps separate persistent RSs would be preferable, rather > > > than a single persistent RS with a large/huge number of > > > pre-allocated m-lines. A persistent RS supporting more than 1 > > > parallel CS might be feasible for a very small number of CSs, > > > as might be encountered at a user's device, so it might be > > > worth retaining the concept. Or we could say that an RS must > > > not support more than one parallel CS, thereby forcing > > > separate RSs for parallel CSs. > > > > > > we will discuss about this solution approach in > > > detail during today's meeting and try to bring the=20 > closure > > > > > > I am not sure I understand the need to bring CS-Group into > > > the solution. Different CSs from the same CS-Group could use > > > the same RS or different RSs - it shouldn't matter. > > > > > > > > > Sorry in case I confused. As you mentioned, there is > > > no restriction w.r.t single CSG in single RS or single CSG in > > > multiple RS and it does not matter. I just provided the > > > example wherein each RS may use same CSG. > > > > > > John (as individual) > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi > > > R (partr) > > > > Sent: 26 January 2011 01:03 > > > > To: siprec@ietf.org; Leon Portman; Henry Lum > > > > Subject: [siprec] Persistent RS session with large set=20 > of CS info > > > > > > > > Leon/Henry, > > > > > > > > The proposal of pre-negotiate large of m-lines in case SRC > supports > > > > large number of sessions is not a optimal solution for the > > following > > > > reason: > > > > > > > > 1) Maintaining such a large number of m-line will be an > > architecture > > > > challenge in as SRC would have maintained very few m-line > > > > till recording > > > > feature is implemented. Let take 200 session supported in > > > > SRC then 400 > > > > m-lines has to be maintained in case of unmixed recording > > > of audio for > > > > two party call and 800 m-lines in case of recording=20 > unmixed audio > & > > > > video call for two party call. > > > > > > > > 2) As John pointed out in another mail thread, it is=20 > not possible > > to > > > > remove m-line once it is created in persistent RS. > > > > > > > > 3) SRC wastes its resources when the number of recording session > is > > > > lower. In case SRC performs lot more services apart from > > > > recording, huge > > > > performance impact will be seen in SRC as the resources are > > > > pre-occupied > > > > for persistent RS. > > > > > > > > In the earlier mail, I have proposed to create=20 > pre-allocated pool > > of > > > > persistent RS for SRC which handle large number=20 > sessions. Each RS > > is > > > > associated with one CS group (CSG) whenever CSG is created, > > > > RS is freed > > > > from CSG when CSG is terminated and RS is re-used for another > > > > CSG later. > > > > Here, persistent RS allocation/de-allocation is > > > > implementation-dependent > > > > and the resource optimization is possible based on=20 > implementation. > > > > > > > > I agree that pre-negotiated persistent RS works for end-point > > > > which acts > > > > as SRC and may work for SRC with few (2-5) sessions. > > > > > > > > Please let me know your opinion here. > > > > > > > > Thanks > > > > Partha > > > > > > > > Topic - Protocol (Henry Lum / Leon Portman) > > > > draft-portman-siprec-protocol-02 > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > > > Draft: > > > https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ > > > > Slides: > > > http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20- > > > > %20virtual%20interim%20Dec%2016%202010.pdf > > > > > > > > Slide 4 (Persistent recording): Leon pointed out that the > > > > whole idea of > > > > persistent recording is not to spend time negotiating m-lines > > > > when a CS > > > > starts - so he prefers the second option on the slide. For SRCs > > that > > > > support a large number of parallel CSs, the SRC could > > > pre-negotiate a > > > > large number of m-lines (perhaps based on licensing),=20 > rather like > > > > provisioning trunks. Paul felt that the other option should > > > > be kept open > > > > - a slight delay in negotiating a new m-line could be handled by > > > > transmitting the data slightly delayed, without losing any. > > > Henry also > > > > mentioned the possibility of the offer-answer failing. It was > > > > questioned > > > > whether there needs to be something in the protocol to indicate > the > > > > delay. This issue should be brought to the list. > > > > > > > > _______________________________________________ > > > > 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 > = From partr@cisco.com Wed Jan 26 08:00:12 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 672E228C0D7 for ; Wed, 26 Jan 2011 08:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.188 X-Spam-Level: X-Spam-Status: No, score=-10.188 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfVIQJOMMwzP for ; Wed, 26 Jan 2011 08:00:08 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id EBFED3A67A3 for ; Wed, 26 Jan 2011 08:00:07 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAvUP01AaMHG/2dsb2JhbACkd3OhC5tJhU8EhRWKYA Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-1.cisco.com with ESMTP; 26 Jan 2011 16:03:07 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0QG341m007294; Wed, 26 Jan 2011 16:03:06 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Jan 2011 21:33:05 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Jan 2011 21:32:14 +0530 Message-ID: In-Reply-To: <059AF07365DC474393A19A3AF187DF7406989D66@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] revised REQ-010 Thread-Index: Acu9J5IVPCoXGIduQ0K4HgOna9O+vwAAp4FQABGaJ2AAAHGeMA== References: <7744FE52C78D944587F03773EB4514610950F6A3@xmb-sjc-22e.amer.cisco.com> <059AF07365DC474393A19A3AF187DF7406989D66@NAHALD.us.int.genesyslab.com> From: "Parthasarathi R (partr)" To: "Henry Lum" , "Elwell, John" , "Ken Rehor (krehor)" , X-OriginalArrivalTime: 26 Jan 2011 16:03:05.0524 (UTC) FILETIME=[8463B740:01CBBD72] Subject: Re: [siprec] revised REQ-010 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 16:00:12 -0000 +1=20 -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum Sent: Wednesday, January 26, 2011 9:19 PM To: Elwell, John; Ken Rehor (krehor); siprec@ietf.org Subject: Re: [siprec] revised REQ-010 +1 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Elwell, John > Sent: Wednesday, January 26, 2011 2:26 AM > To: Ken Rehor (krehor); siprec@ietf.org > Subject: Re: [siprec] revised REQ-010 >=20 > WFM >=20 > John >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Ken Rehor (krehor) > > Sent: 26 January 2011 07:07 > > To: siprec@ietf.org > > Subject: [siprec] revised REQ-010 > > > > > > > > The following is a proposal to change REQ-010. The existing=20 > > requirement is: > > > > > > > > o REQ-010 The mechanism MUST support the ability to deliver to the > > > > SRS multiple media streams for a given CS. > > > > > > > > The proposed new version is: > > > > > > > > o REQ-010 The mechanism MUST support the ability to deliver to the > > SRS multiple media streams of the same or different media types=20 > > for a given CS. > > > > > > > > > > > > Ken > > > > > > > > > > > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec =09 ------------------------------------------------------------------------ ------------------------------------------- CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities. =09 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From partr@cisco.com Wed Jan 26 08:05:11 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B8E93A67D3 for ; Wed, 26 Jan 2011 08:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.896 X-Spam-Level: X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qik13ED0LaBs for ; Wed, 26 Jan 2011 08:05:08 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 7223A3A67A8 for ; Wed, 26 Jan 2011 08:05:08 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK7VP01AaMHG/2dsb2JhbACkd3OhB5tKhU8EhRWKYA Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-3.cisco.com with ESMTP; 26 Jan 2011 16:08:08 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0QG86ka007894; Wed, 26 Jan 2011 16:08:07 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Jan 2011 21:38:06 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Jan 2011 21:37:08 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Persistent RS session with large set of CS info Thread-Index: Acu83pcEUtR/mjUXQMit9DldGQtWeQAD1xmgAA7KipAABHZ9mAAGtQ0eAAGOdHAAAKTQAAAEzJ/wAAAtfSA= References: <07465C1D981ABC41A344374066AE1A2C389F4A5B6B@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD05124D2C@XMB-BGL-417.cisco.com> From: "Parthasarathi R (partr)" To: "Elwell, John" , "Ram Mohan R (rmohanr)" , "Leon Portman" , , X-OriginalArrivalTime: 26 Jan 2011 16:08:06.0565 (UTC) FILETIME=[37D2ED50:01CBBD73] Subject: Re: [siprec] Persistent RS session with large set of CS info X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 16:05:12 -0000 John/Ram, As we discussed in the call, there is no need to restrict based on the number of CS per RS. But there is an need for feedback mechanism (or response code) from SRS to indicate that the maximum limit for number of m-line or size of metadata is reached.=20 Thanks Partha -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Wednesday, January 26, 2011 9:31 PM To: Ram Mohan R (rmohanr); Leon Portman; Parthasarathi R (partr); siprec@ietf.org; Henry.Lum@alcatel-lucent.com Subject: RE: [siprec] Persistent RS session with large set of CS info Ram, Yes, I tend to agree about not restricting the number of CSs per RS on the basis of metadata size, particularly in the light of discussions on the call about sending partial metadata. I think other considerations will deter the use of a single RS for a huge number of parallel CSs - I am thinking of the number of m-lines in the SDP and the fact that this is only allowed to increase and can never decrease. John (as individual)=20 > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: 26 January 2011 13:52 > To: Elwell, John; Leon Portman; Parthasarathi R (partr);=20 > siprec@ietf.org; Henry.Lum@alcatel-lucent.com > Subject: RE: [siprec] Persistent RS session with large set of CS info >=20 > My thoughts on this: >=20 > The metadata model and the format allows multiple CS [ any number of=20 > them] within a single RS. The proposed XML schema of metadata can=20 > accommodate multiple sessions(each with its XML part) and has the=20 > mechanism to distinguish them. >=20 > I do agree that in case we have several CSs [ hundreds on them] the=20 > XML would be huge and we will have to look for ways to compress the=20 > XML body ( which in my opinion should be outside the scope). IMO that=20 > is purely implementation specific[ depending on how much each SRC can=20 > scale to and also depends on the MTU of that network]. >=20 > As such we should not restrict the number of CSs per RS. Probably we=20 > should have some guidelines. >=20 > Ram >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > > Behalf Of Elwell, John > > Sent: Wednesday, January 26, 2011 6:57 PM > > To: Leon Portman; Parthasarathi R (partr); 'siprec@ietf.org';=20 > > 'Henry.Lum@alcatel-lucent.com' > > Subject: Re: [siprec] Persistent RS session with large set > of CS info > >=20 > > That is a decision we need to make - we would just need to consider > the > > implications. For example, as soon as you allow >1 parallel > CS on the > > same RS, you have to decide how to distinguish their > metadatas, e.g., > > multiple body parts, multiple elements in the same XML body > part. Not > > really a problem, just need to figure it out. > >=20 > > John (as individual) > >=20 > > > -----Original Message----- > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > Sent: 26 January 2011 12:37 > > > To: 'partr@cisco.com'; Elwell, John; 'siprec@ietf.org';=20 > > > 'Henry.Lum@alcatel-lucent.com' > > > Subject: Re: Persistent RS session with large set of CS info > > > > > > There was no intent to limit number of m-lines per RS. It is more=20 > > > implementation decision to have one giant RS or multiple Rs=20 > > > blocks. > > > > > > Leon > > > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > Sent: Wednesday, January 26, 2011 11:34 AM > > > To: Elwell, John ; > > > siprec@ietf.org ; Leon Portman; Henry Lum=20 > > > > > > Subject: RE: Persistent RS session with large set of CS info > > > > > > > > > John, > > > > > > Please read inline. > > > > > > Thanks > > > Partha > > > > > > ________________________________ > > > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Wed 1/26/2011 12:54 PM > > > To: Parthasarathi R (partr); siprec@ietf.org; Leon Portman; Henry > Lum > > > Subject: RE: Persistent RS session with large set of CS info > > > > > > > > > > > > I tend to agree with Partha's concerns on scalability. > > > Perhaps separate persistent RSs would be preferable, rather than a > > > single persistent RS with a large/huge number of pre-allocated=20 > > > m-lines. A persistent RS supporting more than 1 parallel CS might=20 > > > be feasible for a very small number of CSs, as might be=20 > > > encountered at a user's device, so it might be worth retaining the > > > concept. Or we could say that an RS must not support more than one > > > parallel CS, thereby forcing separate RSs for parallel CSs. > > > > > > we will discuss about this solution approach in detail=20 > > > during today's meeting and try to bring the > closure > > > > > > I am not sure I understand the need to bring CS-Group into the=20 > > > solution. Different CSs from the same CS-Group could use the same=20 > > > RS or different RSs - it shouldn't matter. > > > > > > > > > Sorry in case I confused. As you mentioned, there is no=20 > > > restriction w.r.t single CSG in single RS or single CSG in=20 > > > multiple RS and it does not matter. I just provided the example=20 > > > wherein each RS may use same CSG. > > > > > > John (as individual) > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi > > > R (partr) > > > > Sent: 26 January 2011 01:03 > > > > To: siprec@ietf.org; Leon Portman; Henry Lum > > > > Subject: [siprec] Persistent RS session with large set > of CS info > > > > > > > > Leon/Henry, > > > > > > > > The proposal of pre-negotiate large of m-lines in case SRC > supports > > > > large number of sessions is not a optimal solution for the > > following > > > > reason: > > > > > > > > 1) Maintaining such a large number of m-line will be an > > architecture > > > > challenge in as SRC would have maintained very few m-line till=20 > > > > recording feature is implemented. Let take 200 session=20 > > > > supported in SRC then 400 m-lines has to be maintained in case=20 > > > > of unmixed recording > > > of audio for > > > > two party call and 800 m-lines in case of recording > unmixed audio > & > > > > video call for two party call. > > > > > > > > 2) As John pointed out in another mail thread, it is > not possible > > to > > > > remove m-line once it is created in persistent RS. > > > > > > > > 3) SRC wastes its resources when the number of recording session > is > > > > lower. In case SRC performs lot more services apart from=20 > > > > recording, huge performance impact will be seen in SRC as the=20 > > > > resources are pre-occupied for persistent RS. > > > > > > > > In the earlier mail, I have proposed to create > pre-allocated pool > > of > > > > persistent RS for SRC which handle large number > sessions. Each RS > > is > > > > associated with one CS group (CSG) whenever CSG is created, RS=20 > > > > is freed from CSG when CSG is terminated and RS is re-used for=20 > > > > another CSG later. > > > > Here, persistent RS allocation/de-allocation is=20 > > > > implementation-dependent and the resource optimization is=20 > > > > possible based on > implementation. > > > > > > > > I agree that pre-negotiated persistent RS works for end-point=20 > > > > which acts as SRC and may work for SRC with few (2-5) sessions. > > > > > > > > Please let me know your opinion here. > > > > > > > > Thanks > > > > Partha > > > > > > > > Topic - Protocol (Henry Lum / Leon Portman) > > > > draft-portman-siprec-protocol-02=20 > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Draft: > > > https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ > > > > Slides: > > > http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20- > > > > %20virtual%20interim%20Dec%2016%202010.pdf > > > > > > > > Slide 4 (Persistent recording): Leon pointed out that the whole=20 > > > > idea of persistent recording is not to spend time negotiating=20 > > > > m-lines when a CS starts - so he prefers the second option on=20 > > > > the slide. For SRCs > > that > > > > support a large number of parallel CSs, the SRC could > > > pre-negotiate a > > > > large number of m-lines (perhaps based on licensing), > rather like > > > > provisioning trunks. Paul felt that the other option should be=20 > > > > kept open > > > > - a slight delay in negotiating a new m-line could be handled by > > > > transmitting the data slightly delayed, without losing any. > > > Henry also > > > > mentioned the possibility of the offer-answer failing. It was=20 > > > > questioned whether there needs to be something in the protocol=20 > > > > to indicate > the > > > > delay. This issue should be brought to the list. > > > > > > > > _______________________________________________ > > > > 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 >=20 From rmohanr@cisco.com Wed Jan 26 08:15:25 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5E0C3A67DF for ; Wed, 26 Jan 2011 08:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.176 X-Spam-Level: X-Spam-Status: No, score=-10.176 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMzHyUXH9zwH for ; Wed, 26 Jan 2011 08:15:24 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 69DE63A67CC for ; Wed, 26 Jan 2011 08:15:23 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8DAMvXP02Q/khMgWdsb2JhbACkdxUBARYiJKELm0uFTwSFFYpg Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 26 Jan 2011 16:18:23 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p0QGIM9h006915; Wed, 26 Jan 2011 16:18:23 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Jan 2011 21:48:22 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Jan 2011 21:48:18 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD05124D4B@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Persistent RS session with large set of CS info Thread-Index: Acu83pcEUtR/mjUXQMit9DldGQtWeQAD1xmgAA7KipAABHZ9mAAGtQ0eAAGOdHAAAKTQAAAEzJ/wAAAtfSAAAG7U0A== References: <07465C1D981ABC41A344374066AE1A2C389F4A5B6B@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD05124D2C@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Parthasarathi R (partr)" , "Elwell, John" , "Leon Portman" , , X-OriginalArrivalTime: 26 Jan 2011 16:18:22.0176 (UTC) FILETIME=[A6C1B600:01CBBD74] Subject: Re: [siprec] Persistent RS session with large set of CS info X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 16:15:25 -0000 Feedback(new response code) from SRS could be one way to do this, but I don't see a need to extend SIP error code for this purpose. The other approach is the SRC itself determines the size of the message has reached the threshold [ say based on the MTU of the network it is in] and decide to spawn another RS to SRS. We could leave it to the implementers and probably just have some guidelines. Regards, Ram > -----Original Message----- > From: Parthasarathi R (partr) > Sent: Wednesday, January 26, 2011 9:37 PM > To: Elwell, John; Ram Mohan R (rmohanr); Leon Portman; siprec@ietf.org; > Henry.Lum@alcatel-lucent.com > Subject: RE: [siprec] Persistent RS session with large set of CS info >=20 > John/Ram, >=20 > As we discussed in the call, there is no need to restrict based on the > number of CS per RS. But there is an need for feedback mechanism (or > response code) from SRS to indicate that the maximum limit for number > of m-line or size of metadata is reached. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Wednesday, January 26, 2011 9:31 PM > To: Ram Mohan R (rmohanr); Leon Portman; Parthasarathi R (partr); > siprec@ietf.org; Henry.Lum@alcatel-lucent.com > Subject: RE: [siprec] Persistent RS session with large set of CS info >=20 > Ram, >=20 > Yes, I tend to agree about not restricting the number of CSs per RS on > the basis of metadata size, particularly in the light of discussions on > the call about sending partial metadata. I think other considerations > will deter the use of a single RS for a huge number of parallel CSs - I > am thinking of the number of m-lines in the SDP and the fact that this > is only allowed to increase and can never decrease. >=20 > John (as individual) >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > Sent: 26 January 2011 13:52 > > To: Elwell, John; Leon Portman; Parthasarathi R (partr); > > siprec@ietf.org; Henry.Lum@alcatel-lucent.com > > Subject: RE: [siprec] Persistent RS session with large set of CS info > > > > My thoughts on this: > > > > The metadata model and the format allows multiple CS [ any number of > > them] within a single RS. The proposed XML schema of metadata can > > accommodate multiple sessions(each with its XML part) and has the > > mechanism to distinguish them. > > > > I do agree that in case we have several CSs [ hundreds on them] the > > XML would be huge and we will have to look for ways to compress the > > XML body ( which in my opinion should be outside the scope). IMO that > > is purely implementation specific[ depending on how much each SRC can > > scale to and also depends on the MTU of that network]. > > > > As such we should not restrict the number of CSs per RS. Probably we > > should have some guidelines. > > > > Ram > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Elwell, John > > > Sent: Wednesday, January 26, 2011 6:57 PM > > > To: Leon Portman; Parthasarathi R (partr); 'siprec@ietf.org'; > > > 'Henry.Lum@alcatel-lucent.com' > > > Subject: Re: [siprec] Persistent RS session with large set > > of CS info > > > > > > That is a decision we need to make - we would just need to consider > > the > > > implications. For example, as soon as you allow >1 parallel > > CS on the > > > same RS, you have to decide how to distinguish their > > metadatas, e.g., > > > multiple body parts, multiple elements in the same XML body > > part. Not > > > really a problem, just need to figure it out. > > > > > > John (as individual) > > > > > > > -----Original Message----- > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > Sent: 26 January 2011 12:37 > > > > To: 'partr@cisco.com'; Elwell, John; 'siprec@ietf.org'; > > > > 'Henry.Lum@alcatel-lucent.com' > > > > Subject: Re: Persistent RS session with large set of CS info > > > > > > > > There was no intent to limit number of m-lines per RS. It is more > > > > implementation decision to have one giant RS or multiple Rs > > > > blocks. > > > > > > > > Leon > > > > > > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > Sent: Wednesday, January 26, 2011 11:34 AM > > > > To: Elwell, John ; > > > > siprec@ietf.org ; Leon Portman; Henry Lum > > > > > > > > Subject: RE: Persistent RS session with large set of CS info > > > > > > > > > > > > John, > > > > > > > > Please read inline. > > > > > > > > Thanks > > > > Partha > > > > > > > > ________________________________ > > > > > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Wed 1/26/2011 12:54 PM > > > > To: Parthasarathi R (partr); siprec@ietf.org; Leon Portman; Henry > > Lum > > > > Subject: RE: Persistent RS session with large set of CS info > > > > > > > > > > > > > > > > I tend to agree with Partha's concerns on scalability. > > > > Perhaps separate persistent RSs would be preferable, rather than > a > > > > single persistent RS with a large/huge number of pre-allocated > > > > m-lines. A persistent RS supporting more than 1 parallel CS might > > > > be feasible for a very small number of CSs, as might be > > > > encountered at a user's device, so it might be worth retaining > the > > > > concept. Or we could say that an RS must not support more than > one > > > > parallel CS, thereby forcing separate RSs for parallel CSs. > > > > > > > > we will discuss about this solution approach in detail > > > > during today's meeting and try to bring the > > closure > > > > > > > > I am not sure I understand the need to bring CS-Group into the > > > > solution. Different CSs from the same CS-Group could use the same > > > > RS or different RSs - it shouldn't matter. > > > > > > > > > > > > Sorry in case I confused. As you mentioned, there is no > > > > restriction w.r.t single CSG in single RS or single CSG in > > > > multiple RS and it does not matter. I just provided the example > > > > wherein each RS may use same CSG. > > > > > > > > John (as individual) > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi > > > > R (partr) > > > > > Sent: 26 January 2011 01:03 > > > > > To: siprec@ietf.org; Leon Portman; Henry Lum > > > > > Subject: [siprec] Persistent RS session with large set > > of CS info > > > > > > > > > > Leon/Henry, > > > > > > > > > > The proposal of pre-negotiate large of m-lines in case SRC > > supports > > > > > large number of sessions is not a optimal solution for the > > > following > > > > > reason: > > > > > > > > > > 1) Maintaining such a large number of m-line will be an > > > architecture > > > > > challenge in as SRC would have maintained very few m-line till > > > > > recording feature is implemented. Let take 200 session > > > > > supported in SRC then 400 m-lines has to be maintained in case > > > > > of unmixed recording > > > > of audio for > > > > > two party call and 800 m-lines in case of recording > > unmixed audio > > & > > > > > video call for two party call. > > > > > > > > > > 2) As John pointed out in another mail thread, it is > > not possible > > > to > > > > > remove m-line once it is created in persistent RS. > > > > > > > > > > 3) SRC wastes its resources when the number of recording > session > > is > > > > > lower. In case SRC performs lot more services apart from > > > > > recording, huge performance impact will be seen in SRC as the > > > > > resources are pre-occupied for persistent RS. > > > > > > > > > > In the earlier mail, I have proposed to create > > pre-allocated pool > > > of > > > > > persistent RS for SRC which handle large number > > sessions. Each RS > > > is > > > > > associated with one CS group (CSG) whenever CSG is created, RS > > > > > is freed from CSG when CSG is terminated and RS is re-used for > > > > > another CSG later. > > > > > Here, persistent RS allocation/de-allocation is > > > > > implementation-dependent and the resource optimization is > > > > > possible based on > > implementation. > > > > > > > > > > I agree that pre-negotiated persistent RS works for end-point > > > > > which acts as SRC and may work for SRC with few (2-5) sessions. > > > > > > > > > > Please let me know your opinion here. > > > > > > > > > > Thanks > > > > > Partha > > > > > > > > > > Topic - Protocol (Henry Lum / Leon Portman) > > > > > draft-portman-siprec-protocol-02 > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > Draft: > > > > https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ > > > > > Slides: > > > > http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20- > > > > > %20virtual%20interim%20Dec%2016%202010.pdf > > > > > > > > > > Slide 4 (Persistent recording): Leon pointed out that the whole > > > > > idea of persistent recording is not to spend time negotiating > > > > > m-lines when a CS starts - so he prefers the second option on > > > > > the slide. For SRCs > > > that > > > > > support a large number of parallel CSs, the SRC could > > > > pre-negotiate a > > > > > large number of m-lines (perhaps based on licensing), > > rather like > > > > > provisioning trunks. Paul felt that the other option should be > > > > > kept open > > > > > - a slight delay in negotiating a new m-line could be handled > by > > > > > transmitting the data slightly delayed, without losing any. > > > > Henry also > > > > > mentioned the possibility of the offer-answer failing. It was > > > > > questioned whether there needs to be something in the protocol > > > > > to indicate > > the > > > > > delay. This issue should be brought to the list. > > > > > > > > > > _______________________________________________ > > > > > 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 > > From pkyzivat@cisco.com Wed Jan 26 08:38:47 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E439A3A67EF for ; Wed, 26 Jan 2011 08:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.896 X-Spam-Level: X-Spam-Status: No, score=-109.896 tagged_above=-999 required=5 tests=[AWL=-0.497, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsUv8IONWcZK for ; Wed, 26 Jan 2011 08:38:46 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 1841A3A63D3 for ; Wed, 26 Jan 2011 08:38:46 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPPcP01AZnwM/2dsb2JhbACkd3OhBZtThU8EhReHEoNG Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 26 Jan 2011 16:41:46 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0QGfkxI011296 for ; Wed, 26 Jan 2011 16:41:46 GMT Message-ID: <4D404ECA.1000902@cisco.com> Date: Wed, 26 Jan 2011 11:41:46 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: siprec@ietf.org References: <07465C1D981ABC41A344374066AE1A2C389F4A5B6B@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD05124D2C@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05124D4B@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD05124D4B@XMB-BGL-417.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Persistent RS session with large set of CS info X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 16:38:48 -0000 On 1/26/2011 11:18 AM, Ram Mohan R (rmohanr) wrote: > Feedback(new response code) from SRS could be one way to do this, but I > don't see a need to extend SIP error code for this purpose. > The other approach is the SRC itself determines the size of the message > has reached the threshold [ say based on the MTU of the network it is > in] and decide to spawn another RS to SRS. We could leave it to the > implementers and probably just have some guidelines. Too many m-lines could be dealt with by a 488 response. (We might need a new Warn code.) This error would not be specific to siprec. But it would be wise to avoid getting the error. Thanks, Paul > Regards, > Ram > >> -----Original Message----- >> From: Parthasarathi R (partr) >> Sent: Wednesday, January 26, 2011 9:37 PM >> To: Elwell, John; Ram Mohan R (rmohanr); Leon Portman; > siprec@ietf.org; >> Henry.Lum@alcatel-lucent.com >> Subject: RE: [siprec] Persistent RS session with large set of CS info >> >> John/Ram, >> >> As we discussed in the call, there is no need to restrict based on the >> number of CS per RS. But there is an need for feedback mechanism (or >> response code) from SRS to indicate that the maximum limit for number >> of m-line or size of metadata is reached. >> >> Thanks >> Partha >> >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> Sent: Wednesday, January 26, 2011 9:31 PM >> To: Ram Mohan R (rmohanr); Leon Portman; Parthasarathi R (partr); >> siprec@ietf.org; Henry.Lum@alcatel-lucent.com >> Subject: RE: [siprec] Persistent RS session with large set of CS info >> >> Ram, >> >> Yes, I tend to agree about not restricting the number of CSs per RS on >> the basis of metadata size, particularly in the light of discussions > on >> the call about sending partial metadata. I think other considerations >> will deter the use of a single RS for a huge number of parallel CSs - > I >> am thinking of the number of m-lines in the SDP and the fact that this >> is only allowed to increase and can never decrease. >> >> John (as individual) >> >>> -----Original Message----- >>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>> Sent: 26 January 2011 13:52 >>> To: Elwell, John; Leon Portman; Parthasarathi R (partr); >>> siprec@ietf.org; Henry.Lum@alcatel-lucent.com >>> Subject: RE: [siprec] Persistent RS session with large set of CS > info >>> >>> My thoughts on this: >>> >>> The metadata model and the format allows multiple CS [ any number of >>> them] within a single RS. The proposed XML schema of metadata can >>> accommodate multiple sessions(each with its XML part) and has the >>> mechanism to distinguish them. >>> >>> I do agree that in case we have several CSs [ hundreds on them] the >>> XML would be huge and we will have to look for ways to compress the >>> XML body ( which in my opinion should be outside the scope). IMO > that >>> is purely implementation specific[ depending on how much each SRC > can >>> scale to and also depends on the MTU of that network]. >>> >>> As such we should not restrict the number of CSs per RS. Probably we >>> should have some guidelines. >>> >>> Ram >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of Elwell, John >>>> Sent: Wednesday, January 26, 2011 6:57 PM >>>> To: Leon Portman; Parthasarathi R (partr); 'siprec@ietf.org'; >>>> 'Henry.Lum@alcatel-lucent.com' >>>> Subject: Re: [siprec] Persistent RS session with large set >>> of CS info >>>> >>>> That is a decision we need to make - we would just need to > consider >>> the >>>> implications. For example, as soon as you allow>1 parallel >>> CS on the >>>> same RS, you have to decide how to distinguish their >>> metadatas, e.g., >>>> multiple body parts, multiple elements in the same XML body >>> part. Not >>>> really a problem, just need to figure it out. >>>> >>>> John (as individual) >>>> >>>>> -----Original Message----- >>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] >>>>> Sent: 26 January 2011 12:37 >>>>> To: 'partr@cisco.com'; Elwell, John; 'siprec@ietf.org'; >>>>> 'Henry.Lum@alcatel-lucent.com' >>>>> Subject: Re: Persistent RS session with large set of CS info >>>>> >>>>> There was no intent to limit number of m-lines per RS. It is > more >>>>> implementation decision to have one giant RS or multiple Rs >>>>> blocks. >>>>> >>>>> Leon >>>>> >>>>> >>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>> Sent: Wednesday, January 26, 2011 11:34 AM >>>>> To: Elwell, John; >>>>> siprec@ietf.org; Leon Portman; Henry Lum >>>>> >>>>> Subject: RE: Persistent RS session with large set of CS info >>>>> >>>>> >>>>> John, >>>>> >>>>> Please read inline. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>> ________________________________ >>>>> >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>> Sent: Wed 1/26/2011 12:54 PM >>>>> To: Parthasarathi R (partr); siprec@ietf.org; Leon Portman; > Henry >>> Lum >>>>> Subject: RE: Persistent RS session with large set of CS info >>>>> >>>>> >>>>> >>>>> I tend to agree with Partha's concerns on scalability. >>>>> Perhaps separate persistent RSs would be preferable, rather than >> a >>>>> single persistent RS with a large/huge number of pre-allocated >>>>> m-lines. A persistent RS supporting more than 1 parallel CS > might >>>>> be feasible for a very small number of CSs, as might be >>>>> encountered at a user's device, so it might be worth retaining >> the >>>>> concept. Or we could say that an RS must not support more than >> one >>>>> parallel CS, thereby forcing separate RSs for parallel CSs. >>>>> >>>>> we will discuss about this solution approach in detail >>>>> during today's meeting and try to bring the >>> closure >>>>> >>>>> I am not sure I understand the need to bring CS-Group into the >>>>> solution. Different CSs from the same CS-Group could use the > same >>>>> RS or different RSs - it shouldn't matter. >>>>> >>>>> >>>>> Sorry in case I confused. As you mentioned, there is no >>>>> restriction w.r.t single CSG in single RS or single CSG in >>>>> multiple RS and it does not matter. I just provided the example >>>>> wherein each RS may use same CSG. >>>>> >>>>> John (as individual) >>>>> >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org >>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi >>>>> R (partr) >>>>>> Sent: 26 January 2011 01:03 >>>>>> To: siprec@ietf.org; Leon Portman; Henry Lum >>>>>> Subject: [siprec] Persistent RS session with large set >>> of CS info >>>>>> >>>>>> Leon/Henry, >>>>>> >>>>>> The proposal of pre-negotiate large of m-lines in case SRC >>> supports >>>>>> large number of sessions is not a optimal solution for the >>>> following >>>>>> reason: >>>>>> >>>>>> 1) Maintaining such a large number of m-line will be an >>>> architecture >>>>>> challenge in as SRC would have maintained very few m-line till >>>>>> recording feature is implemented. Let take 200 session >>>>>> supported in SRC then 400 m-lines has to be maintained in case >>>>>> of unmixed recording >>>>> of audio for >>>>>> two party call and 800 m-lines in case of recording >>> unmixed audio >>> & >>>>>> video call for two party call. >>>>>> >>>>>> 2) As John pointed out in another mail thread, it is >>> not possible >>>> to >>>>>> remove m-line once it is created in persistent RS. >>>>>> >>>>>> 3) SRC wastes its resources when the number of recording >> session >>> is >>>>>> lower. In case SRC performs lot more services apart from >>>>>> recording, huge performance impact will be seen in SRC as the >>>>>> resources are pre-occupied for persistent RS. >>>>>> >>>>>> In the earlier mail, I have proposed to create >>> pre-allocated pool >>>> of >>>>>> persistent RS for SRC which handle large number >>> sessions. Each RS >>>> is >>>>>> associated with one CS group (CSG) whenever CSG is created, RS >>>>>> is freed from CSG when CSG is terminated and RS is re-used for >>>>>> another CSG later. >>>>>> Here, persistent RS allocation/de-allocation is >>>>>> implementation-dependent and the resource optimization is >>>>>> possible based on >>> implementation. >>>>>> >>>>>> I agree that pre-negotiated persistent RS works for end-point >>>>>> which acts as SRC and may work for SRC with few (2-5) > sessions. >>>>>> >>>>>> Please let me know your opinion here. >>>>>> >>>>>> Thanks >>>>>> Partha >>>>>> >>>>>> Topic - Protocol (Henry Lum / Leon Portman) >>>>>> draft-portman-siprec-protocol-02 >>>>>> ================================================ >>>>>> Draft: >>>>> https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ >>>>>> Slides: >>>>> http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20- >>>>>> %20virtual%20interim%20Dec%2016%202010.pdf >>>>>> >>>>>> Slide 4 (Persistent recording): Leon pointed out that the > whole >>>>>> idea of persistent recording is not to spend time negotiating >>>>>> m-lines when a CS starts - so he prefers the second option on >>>>>> the slide. For SRCs >>>> that >>>>>> support a large number of parallel CSs, the SRC could >>>>> pre-negotiate a >>>>>> large number of m-lines (perhaps based on licensing), >>> rather like >>>>>> provisioning trunks. Paul felt that the other option should be >>>>>> kept open >>>>>> - a slight delay in negotiating a new m-line could be handled >> by >>>>>> transmitting the data slightly delayed, without losing any. >>>>> Henry also >>>>>> mentioned the possibility of the offer-answer failing. It was >>>>>> questioned whether there needs to be something in the protocol >>>>>> to indicate >>> the >>>>>> delay. This issue should be brought to the list. >>>>>> >>>>>> _______________________________________________ >>>>>> 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 > From eckelcu@cisco.com Wed Jan 26 10:53:17 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3D563A680D for ; Wed, 26 Jan 2011 10:53:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.309 X-Spam-Level: X-Spam-Status: No, score=-10.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EL7GJwtZb+JW for ; Wed, 26 Jan 2011 10:53:17 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 77C833A67FF for ; Wed, 26 Jan 2011 10:53:16 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AosFAJL9P02rR7H+/2dsb2JhbACWWI4gc6FKm1+FTwSFF4pe Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 26 Jan 2011 18:56:01 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0QIu1VQ016810 for ; Wed, 26 Jan 2011 18:56:01 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Jan 2011 10:56:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: lFc= AQBj A3XL BFjF Bajt BmBT CzeE Dx4o FyPc Hba+ HkHA IFNp JHO9 KD8k K84s LLI+; 1; cwBpAHAAcgBlAGMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {79772BBB-A94A-4BC6-AB35-17FB77CC4C91}; ZQBjAGsAZQBsAGMAdQBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Wed, 26 Jan 2011 18:55:58 GMT; bQBlAHQAYQBkAGEAdABhACAAbQBvAGQAZQBsACAAZgBvAHIAIABwAGEAcgB0AGkAYwBpAHAAYQBuAHQAIAB0AGgAYQB0ACAAaQBzACAAbgBvAHQAIABwAGEAcgB0ACAAbwBmACAAQwBTAA== x-cr-puzzleid: {79772BBB-A94A-4BC6-AB35-17FB77CC4C91} Content-class: urn:content-classes:message Date: Wed, 26 Jan 2011 10:55:58 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: metadata model for participant that is not part of CS Thread-Index: Acu9iqr7ynF7z4Y5QUaRyQBZjCoEsQ== From: "Charles Eckel (eckelcu)" To: X-OriginalArrivalTime: 26 Jan 2011 18:56:01.0373 (UTC) FILETIME=[ACE0A0D0:01CBBD8A] Subject: [siprec] metadata model for participant that is not part of CS X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 18:53:18 -0000 This is to follow up on some questions I raised regarding the metadata model during the interim meeting Tuesday. My initial concern was that I thought we were allowing media streams to be defined without any participant. I now understand that is not the case; rather, a media stream is always associated with at least one participant, but that participant need not necessary be associated with the CS. Now I have some concern about participants that are not part of the CS. My concern is that the level of metadata we have for such participants will be inconsistent at best. If the metadata for a non-CS participant is incomplete, what do we plan to do?=20 Also, I believe there was reference to a document that contains the model and some use cases. Which document is that? Thanks, Charles=20 From john.elwell@siemens-enterprise.com Wed Jan 26 12:56:04 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0AE13A69D2 for ; Wed, 26 Jan 2011 12:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.24 X-Spam-Level: X-Spam-Status: No, score=-102.24 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pb1PuZMkz1zn for ; Wed, 26 Jan 2011 12:56:02 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id D92093A6897 for ; Wed, 26 Jan 2011 12:56:01 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3150572 for siprec@ietf.org; Wed, 26 Jan 2011 21:59:02 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 77C681EB82AE for ; Wed, 26 Jan 2011 21:59:02 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 26 Jan 2011 21:59:02 +0100 From: "Elwell, John" To: "siprec@ietf.org" Date: Wed, 26 Jan 2011 21:59:00 +0100 Thread-Topic: Draft minutes Thread-Index: Acu9m9swu0O7wfFvRNa6X5cr9cFPwg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Draft minutes X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 20:56:04 -0000 Please let me have any corrections by end of next week (2011-02-04). John Minutes of the SIPREC WG Interim Virtual Meeting 2011-01-25, 15.00-17.00 GMT/UTC and 2011-01-25, 14.00-16.00 GMT/UTC =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Meeting chaired by Brian Rosen and John Elwell. Participants (session 1): Brian Rosen, John Elwell, Ken Rehor, Leon Portman= , Henry Lum, Ram Mohen, Andy Hutton, Alan Johnston, Gonzalo Camarillo, Paul Kyzivat, Dave Sm= ith, Parthasarathi, Dan Romascanu, Alissa Cooper, Charles Eckel Participants (session 2): Brian Rosen, John Elwell, Ken Rehor, Leon Portman= , Henry Lum, Ram Mohen, Andy Hutton, Alan Johnston, Paul Kyzivat, Dave Smith, Parthasarathi,= Dan Romascanu, Charles Eckel Minutes produced by John Elwell. Webex chat: See end of these minutes (used in session 1 only). Jabber was n= ot used. Recording (session 1): https://workgreen.webex.com/workgreen/ldr.php?AT=3Dp= b&SP=3DMC&rID=3D8263017&rKey=3D19329980a044b45b Recording (session 2): https://workgreen.webex.com/workgreen/ldr.php?AT=3Dp= b&SP=3DMC&rID=3D8280267&rKey=3Db1c328313c4a985d Session 1 started at 15.02 on 2011-01-25 Topic - Administrivia (chairs) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Slides: http://kenrehor.com/ietf/siprec/IETF79.2/Chairs.pdf No changes to published agenda. Topic - Requirements (Ken Rehor) draft-ietf-siprec-req-06 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-req/ Slides: http://kenrehor.com/ietf/siprec/IETF79.2/IETF-79.2-SIPREC-Req-2011-= 01-25.pdf Slide 4 - proposal to delete REQ-015/016. It was noted that these requirem= ents talk about "cancel and discard". After some discussion, there seemed t= o be agreement that the "cancel" part was covered by other requirements (e.= g., you can pause and not resume, effectively cancelling). So the main issu= e concerned the "discard" part. It was noted that previous agreements relat= ing to privacy had reached the conclusion that the retention of recordings = is an issue for the SRS, and outside the scope of SIPREC. There was no obje= ction to deleting the two requirements. Although the main focus of the requirements is on what happens on the SRC-S= RS interface, Dave Smith brought up the question of whether a participant, = whose SIP UA might not be collocated with the SRC, can request the pausing = / stopping of a recording, or even request deletion of the recording. This = would be a requirement impacting the CS, as opposed to the RS, and it was n= oted that none of the solution work has touched on that (although the earli= er draft from Alan Johnston did have provision for an indication on the CS= signalling path that recording is taking place, but this was not brought f= orward into the present protocol draft). Dave was invited to raise on the l= ist any fresh requirements concerning what CS participants might be able to= request. Slide 5 - proposed new requirement on multiple media streams for the same m= edia type. It was observed that REQ-010 was probably intended to cover this= case, and Ken will propose words to enhance REQ-010 to make it clearer. Slide 6 - removal of REQ-021. There was no objection to removal. Ken will try to seek resolution of the issues above and then publish -07, w= hich should be very close to being ready to submit to the IESG. Topic - Metadata model (Ram Mohan) draft-ram-siprec-metadata-03 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Draft: https://datatracker.ietf.org/doc/draft-ram-siprec-metadata/ Slides: http://kenrehor.com/ietf/siprec/IETF79.2/SIPREC%20Metamodel%20-%20V= irtual%20Interim-Jan25_2011.ppt Slide 4: Ram explained why an association between Media Stream and CS had b= een introduced, because of the injection of things like music on hold, lead= ing to a media stream without participant. Charles wondered why music on ho= ld could not be considered a participant. Ram and Paul explained there were= also conference cases where a participant might host a conference on his d= evice, but those behind the conferencing device might not be considered CS = participants. Charles asked why the conference focus could not be considere= d a participant. Paul explained that the SRC could obtain, using the confer= ence event package, a list of participants from the focus, and those partic= ipants would contribute to the media stream, but those participants would n= ot be part of the CS - that would be the role of the focus. Henry thought a= mixer might be considered a participant, but Paul explained that if you ca= n obtain a roster of people behind the mixer, those might be considered par= ticipants rather than the mixer. So there can be participants in the media = that are not participants in the CS. Charles was worried that some media st= reams might not have any identified participants who are generating the str= eam. Paul explained that, assuming the media from the participants are mixe= d, you would see one media stream and a list of participants. One participa= nt might be joined to the CS and the others would not be. Paul thinks we ne= ed to explore some use cases and see how they would be represented using th= is model. So if people have particular use cases, make them known and we ca= n check how they would be represented. Ram will solicit use cases. Partha a= lso had concerns similar to those of Charles, but Charles was beginning to = see how the present model might work if you can get information about non-C= S participants who are generating a media stream. Paul pointed out that the= model does cater for a participant that is not part of a CS. Charles was i= nvited to post his continued concerns / scenarios to the list, but Paul thi= nks the use cases concerned are already covered by the model. Slide 6 (CS Group): Nobody on list had come up with a reason for having mor= e than one CSG associated with a single CS, and the conclusion reached on t= he list seems to stand. Slide 7 (CS): No comments on CS slide, except that forced deletion is to be= removed in line with the requirements discussion. Slide 8 (Participant): Clarified that the multiple AORs are aliases, in the= sense of P-Asserted-Identity being able to carry aliases. Concerning the issue of whether participant role is needed as an attribute,= Leon suggested it could be done in application data, but asked whether we = would then publish some application data dictionary. Paul suggested that ap= plication data is just some additional XML in some other namespace, so some= other group could get together and define it. Leon was concerned that with= out some sort of standardization, different vendors would implement it diff= erently. John suggested we need to decide what things are needed by 80% of = deployments and standardize those in this group, so if that is the case for= participant role, we should standardize it. Partha wanted to include parti= cipant role, even though there might be some cases where it is not availabl= e. Paul pointed out that we had had considerable list discussion on the dif= ficulties of figuring out the role: UAC/UAS is transaction specific, inboun= d/outbound is problematic, and incoming/outgoing, whilst it might work in s= ome cases, it will not always work. Perhaps those focused on call centres c= an say what might/might not work. In conclusion, this has to be taken back = to the list. Without repeating the old arguments, those wanting to include = participant role should indicate what are the likely mechanisms that might = support it. Slide 10 (Media Stream): How to model media streams that are not recorded (= rejected by SRS or no capability at SRS). Dave thought it was important tha= t you have some information in the metadata that there was media that was a= vailable for recording but couldn't be recorded, but there are two cases: w= here you don't want to record, or where, because of a temporary limitation,= you are unable to record but might want to record later. Paul agreed, but = was concerned about the details, although that is very much down to the mec= hanism, e.g., does the SRC need to keep offering the stream? Partha asked a question on start time and end time. Ram clarified that thes= e are start and end times of the CS media. It was pointed out that we have = wall clock time in the metadata, and other times can be relative. Leon sugg= ested there may be a need to retransmit wall clock time occasionally, to co= mpensate for drift. Henry asked whether media stream reference should be part of the mechanism = rather than an attribute. Slide 10 (Application data): Leon agreed with the extensible approach, base= d on different namespaces. Paul said that he would be tempted to stop calli= ng it application data and call it extension data. John (from the floor) qu= estioned whether it really is an object, or just attributes of other object= s. Paul said it was just an artefact of how the model is drawn, but in the = solution it would just be extensibility data. The authors will rework this = with these comments in mind. On next steps, people are asked to review and submit further comments on -0= 3, and -04 will be produced in due course, after which we might be consider= adoption as a WG item. In particular, we need closure on the long discussi= on of media stream relationships. Topic - Protocol (Henry Lum / Leon Portman) draft-portman-siprec-protocol-02 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Draft: https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ Slides: http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20- %20virtual%20interim%20Dec%2016%202010.pdf Slide 4 (Persistent recording): Leon pointed out that the whole idea of per= sistent recording is not to spend time negotiating m-lines when a CS starts= - so he prefers the second option on the slide. For SRCs that support a la= rge number of parallel CSs, the SRC could pre-negotiate a large number of m= -lines (perhaps based on licensing), rather like provisioning trunks. Paul = felt that the other option should be kept open - a slight delay in negotiat= ing a new m-line could be handled by transmitting the data slightly delayed= , without losing any. Henry also mentioned the possibility of the offer-ans= wer failing. It was questioned whether there needs to be something in the p= rotocol to indicate the delay. This issue should be brought to the list. Session 1 wrap-up =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D It was agreed that on the second day we will start by completing the Protoc= ol topic and then do the metadata format topic. Session 1 was closed at 17.00. Session 2 started at 14.02 on 2011-01-26 Topic - Administrivia (chairs) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Agenda as agreed at close of session 1 Topic - Protocol (continued) (Henry Lum / Leon Portman) draft-portman-siprec-protocol-02 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Draft: https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ Slides: http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20- %20virtual%20interim%20Dec%2016%202010.pdf Slide 5 (Transporting metadata): Question of whether we want just one mecha= nism (INVITE/UPDATE or INFO) or two. Paul thinks metadata needs to go in me= ssages with offer/answer, which means INVITE or UPDATE, the latter also bei= ng suitable for exchanging metadata without offer/answer. Brian agreed. Hen= ry had some concerns as to how errors in the metadata might be dealt with u= sing UPDATE, and in particular whether it would mean that offer/answer woul= d need to be considered to have failed if metadata is in error. After consi= derable discussion, it was agreed that the authors should explore the use o= f re-INVITE/UPDATE further as the sole mechanism (i.e., not using INFO), ta= king into account Henry's concerns. Paul thinks we will also need to consider how big the metadata can be, and = therefore whether SIP is the most appropriate transport. Brian suggested we= might need to pass a reference, and Paul suggested we might need a separat= e channel if this was going to be a regular occurrence. However, we first n= eed to see whether there is indeed a problem (see also discussion under the= next agenda item concerning partial metadata). It was noted that the messa= ge would probably need to go TCP end-to-end. Partha asked whether it could = be broken up when it exceeds the max. MTU size. The issue of needing TCP wa= s noted, but this is not a problem unique to SIPREC. John referred to the o= vernight mailing list discussion on multiple parallel CSs per RS, arising f= rom the discussion during session 1. Brian does not want to limit on basis = of XML body size, but John was more concerned about the impact on SDP. It w= as agreed that in such circumstances you can create another SRS - we probab= ly don't need a fixed rule. Partha suggested a possible error message to sa= y the size limit has been exceeded. Discussion to be moved to the list. Slide 7 (Error handling): There was no objection to the assertion that we n= eed a mechanism for SRS to report an error in metadata. The other question = is how soon the response needs to come, i.e., in the SIP response or later.= Charles can see it working either way, with appropriate referencing. Henry= pointed out that sequencing is also an issue if we don't send complete met= adata every time and you need to build a snapshot. Paul raised the question= of whether all metadata transmissions are acknowledged or only those in er= ror. Partha asked why an SRS might want to defer processing and therefore d= efer its response. Charles and Paul pointed out that a timely response is n= eeded to UPDATE, and you need to cater for doing metadata processing on a d= ifferent thread at the SRS. Partha suggested re-INVITE would allow a slower= response. Paul suggested it could be problematic if it takes a long time. Henry came back to case where the offer is OK but the metadata is in error.= For example, can recording proceed without good metadata until the metadat= a is sorted out? So would this be a case for separating metadata update fro= m offer-answer? Paul says this relates to the persistent recording problem = Leon had brought up, where the media is already established and the metadat= a arrives later. Paul suggested we might need flexibility as to whether to = respond immediately (in SIP response) or later. Alan re-iterated the SIP tr= ansaction rules, and noted that we probably need to do responses at a layer= above SIP. Henry observed that his original proposal for INFO would achiev= e a complete separation. Glare issues were also mentioned - glare could occ= ur if there is a need to send UPDATE from SRS to SRC for sending an error. = Partha mentioned using re-INVITE and sending SDP without offer. But others = pointed out that the UAS will then generate an offer - we can't use re-INVI= TE for an offerless transaction, unlike UPDATE. re-INVITE would be possible= , but can only be used in accordance with RFC 3261, e.g., for transferring = the session. Slide 10 (Recording-aware UA on CS requesting no-record before start of ses= sion - REQ-017). John thought this would not be in line with the semantics = of option tags. Leon suggested using SDP, which would allow no-record to be= done on a per medium basis. This should be taken to the list. Slide 11 (Indicating to recording-aware UA on CS that session is being reco= rded - REQ-018): Paul suggested that an SDP-based solution should be explor= ed for this too. Partha asked about whether we need to specify anything con= cerning how we notify in audio. The consensus seemed to be that there is no= thing we can standardize here. The authors should explore solutions to REQ-017 and REQ-018 further. Topic - Metadata Format (Partha) draft-portman-siprec-protocol-02 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Draft: https://datatracker.ietf.org/doc/draft-ram-siprec-metadata-format/ Slides: http://kenrehor.com/ietf/siprec/IETF79.2/SIPREC%20Metamodel%20Forma= t-%20Interim-Jan25&26-2010.pdf Slide 3 (Issue of JSON for compressed XML): Paul thinks it is not so well s= tandardized yet and the extensibility mechanisms (very important to us) are= not understood so well, but he is willing to be educated if somebody has g= reater insight. Henry felt that it might be hard to make it interoperable. = Paul had been told by an XML expert in his company and in IETF that if XML = is too big, use GZIP - no other compression scheme will achieve interoperab= ility. As a working assumption we will proceed with XML. Slide 6 (group element): Ram noted that according to very recent list discu= ssion, the Initiator element should be moved to appdata. Slide 8 (participant element); Ram clarified that the "recv" element was ad= ded to address the case of side conversations, where some streams are recei= ved only by some participants. Slide 10 (appdata element): Paul pointed out it would be good if we can get= an XML expert who is also active in SIPREC - he is not sure if xs:any is a= n appropriate and sufficient extensibility mechanism. Slide 11 (Container elements): Again Paul would like XML expertise on this. Slide 12 (Open issue on id generation): Ram thinks it might be better if t= he id, or part of it, is generated by the SRS, to make it more useful for s= ubsequent retrieval. Partha stated that this would not be possible for the = group id, which would need to be generated by the SRC. Ram agrees for the g= roup id, but for other elements prefers the SRS. Paul is trying to understa= nd the scope of the identifiers. So if scope is a single SRC, what Ram says= is reasonable - the SRS can generate part of every id, i.e., the part that= identifies the SRC. What concerns Paul is if there is anything that needs = to be referenced by things created by two different SRCs - he doesn't think= there is at present. But we might need an extensible mechanism so that suc= h cases can be handled if they arise in the future. Leon mentioned multiple SRSs. Paul wanted to know whether these are indepen= dent or with shared data - if completely independent, it doesn't matter - i= t only complicates things if the SRC includes something like a seed obtaine= d from the SRS and then talks to an independent SRS. Leon wanted to know wh= y the SRC can't produce the ID anyway. Paul says this is doable, even if th= e id's need to be globally unique, but do we need it? It will make the keys= bigger and put more work on the SRC. Slide 15 (Partial metadata in XML): Paul thinks this is the elephant in the= room - a huge issue. Henry thinks the main concern is that if we always se= nd an entire snapshot, the SRS has to figure out what has changed. Also the= SRC has to remember history in order to construct the entire metadata each= time it sends. Charles thinks it is not scalable for big conferences. So t= here seems to be an opinion that we need a mechanism to send partial inform= ation. It is perhaps simpler than some applications in that you never delet= e (e.g., even if a party drops out, you add the fact he has dropped out). C= harles asked about querying the metadata - it was noted that this is curren= tly out of scope. There seems to be no disagreement we that need to have so= me partial updating mechanism. Partha will investigate possible mechanisms. Next steps slide: The most pressing issues are finding a proposal for part= ial metadata and understanding the scope of identifiers. On the question of= whether we should keep the format and model drafts separate, it was sugges= ted we could even have more than one format. At least for now they should b= e kept separate. Session 2 wrap-up =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D In summary, John reflected that we had brought the requirements draft near = to completion, that the metadata model draft was close to a point where we = could consider adoption as a WG item (subject to clarifying a few issues), = and really useful early discussions were held on the protocol and metadata = format drafts. The architecture document is basically on hold, awaiting pro= gress on the other drafts before finalising it. Much now needs to be done o= n the mailing list, and no need was seen for a further interim virtual meet= ing (unless anything crops up that prevents us getting the requirements doc= ument out of the door in a timely manner). The chairs will request a 2 hour= slot in Prague. Session 2 was closed at 15.48. Day 1 chat log =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D January 25, 2011 3:19:58 PM from Alissa Cooper to Everyone: I'm not in a place where I can speak in the audio, but I th= ink we decided not to have requirements related to what happens to the reco= rding after it has been made. January 25, 2011 3:30:32 PM from Alissa Cooper to Everyone: it seems like there are cases where the hints are valuable = even if they aren't always honored January 25, 2011 3:39:51 PM from Alissa Cooper to Everyone: it's old, I'll take it to the list January 25, 2011 4:59:32 PM from Kenneth Rehor to Everyone: Unfortunately I have to drop off now. TTY tomorrow. From Henry.Lum@alcatel-lucent.com Wed Jan 26 13:25:04 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ADAB3A69E3 for ; Wed, 26 Jan 2011 13:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.161 X-Spam-Level: X-Spam-Status: No, score=-6.161 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IefzHZDNQhLH for ; Wed, 26 Jan 2011 13:25:02 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id C73EB3A69D9 for ; Wed, 26 Jan 2011 13:25:01 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p0QLS1bg029854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Jan 2011 15:28:02 -0600 (CST) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [172.22.68.187]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0QLS0j9027140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Jan 2011 15:28:01 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id p0QLRxl0005723; Wed, 26 Jan 2011 13:27:59 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Jan 2011 13:27:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Jan 2011 13:27:58 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF7406989EA5@NAHALD.us.int.genesyslab.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] metadata model for participant that is not part of CS Thread-Index: Acu9iqr7ynF7z4Y5QUaRyQBZjCoEsQAFBbgQ References: From: "Henry Lum" To: "Charles Eckel (eckelcu)" , X-OriginalArrivalTime: 26 Jan 2011 21:27:59.0436 (UTC) FILETIME=[E7AAA0C0:01CBBD9F] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [siprec] metadata model for participant that is not part of CS X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 21:25:04 -0000 Trying to come up with an instance diagram for what a conference mixer looks like: +-------------------------------+ | Recording Session (RS) | +-------------------------------+ | | +-------------------------------+ | Communication Session (CS) | | Group(CSG) | +-------------------------------+ | Unique-id1 | +-------------------------------+ | | =20 +----------------+ =20 | Communication | =20 | Session (CS)1 | =20 +----------------+ =20 | | =20 +----------------+ =20 | =20 |-------------------+ | | +---------------+ +---------------+ | ParticipantA |--+--| ParticipantB | +---------------+ | +---------------+ | | | sends receives sends | | | +---------------+ | +---------------+ |Media Stream A | | |Media Stream B | +---------------+ | +---------------+ | +---------------+ |Media Stream C | | (mixed stream)| +---------------+ | sends | +---------------+=20 | ParticipantC |=20 | (automated |=20 | announcement)|=20 +---------------+ Media Stream C is the one that we are interested in and that is the recorded stream in the RS. It looks to me that we need some form of an automated participant that produces the mixed media as well as acting as an automated participant that produces any announcements to the conference mix. This way we can tell who generated the announcements as well as the mix itself, however, I have a the same question as Charles where it is unclear to me whether this automated participant should belong to any CS. Regards, Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Charles Eckel (eckelcu) > Sent: Wednesday, January 26, 2011 1:56 PM > To: siprec@ietf.org > Subject: [siprec] metadata model for participant that is not part of CS >=20 > This is to follow up on some questions I raised regarding the metadata > model during the interim meeting Tuesday. > My initial concern was that I thought we were allowing media streams to > be defined without any participant. I now understand that is not the > case; rather, a media stream is always associated with at least one > participant, but that participant need not necessary be associated with > the CS. > Now I have some concern about participants that are not part of the CS. > My concern is that the level of metadata we have for such participants > will be inconsistent at best. If the metadata for a non-CS participant > is incomplete, what do we plan to do? > Also, I believe there was reference to a document that contains the > model and some use cases. Which document is that? >=20 > Thanks, > Charles > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From Henry.Lum@alcatel-lucent.com Wed Jan 26 13:26:24 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BBF83A69EB for ; Wed, 26 Jan 2011 13:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.582 X-Spam-Level: X-Spam-Status: No, score=-5.582 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7jT93Q3AgoL for ; Wed, 26 Jan 2011 13:26:21 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id F368D3A69E3 for ; Wed, 26 Jan 2011 13:26:20 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p0QLTK12007501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Jan 2011 15:29:20 -0600 (CST) Received: from relay-out2.dc (relay-out2.dc.genesyslab.com [172.22.68.188]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0QLTIRa032674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Jan 2011 15:29:20 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc (8.13.8+Sun/8.13.8) with ESMTP id p0QLTI2u007685; Wed, 26 Jan 2011 13:29:18 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Jan 2011 13:29:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Jan 2011 13:29:15 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF7406989EA6@NAHALD.us.int.genesyslab.com> In-Reply-To: <4D404ECA.1000902@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Persistent RS session with large set of CS info Thread-Index: Acu9d/DravbH4eOUQoydRS1yh30XLwAKBcHg References: <07465C1D981ABC41A344374066AE1A2C389F4A5B6B@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD05124D2C@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05124D4B@XMB-BGL-417.cisco.com> <4D404ECA.1000902@cisco.com> From: "Henry Lum" To: "Paul Kyzivat" , X-OriginalArrivalTime: 26 Jan 2011 21:29:18.0076 (UTC) FILETIME=[168A23C0:01CBBDA0] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [siprec] Persistent RS session with large set of CS info X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 21:26:24 -0000 Agreed; I don't think this error should be specific to siprec. Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Wednesday, January 26, 2011 11:42 AM > To: siprec@ietf.org > Subject: Re: [siprec] Persistent RS session with large set of CS info >=20 >=20 >=20 > On 1/26/2011 11:18 AM, Ram Mohan R (rmohanr) wrote: > > Feedback(new response code) from SRS could be one way to do this, but > I > > don't see a need to extend SIP error code for this purpose. > > The other approach is the SRC itself determines the size of the > message > > has reached the threshold [ say based on the MTU of the network it is > > in] and decide to spawn another RS to SRS. We could leave it to the > > implementers and probably just have some guidelines. >=20 > Too many m-lines could be dealt with by a 488 response. (We might need > a > new Warn code.) This error would not be specific to siprec. >=20 > But it would be wise to avoid getting the error. >=20 > Thanks, > Paul >=20 > > Regards, > > Ram > > > >> -----Original Message----- > >> From: Parthasarathi R (partr) > >> Sent: Wednesday, January 26, 2011 9:37 PM > >> To: Elwell, John; Ram Mohan R (rmohanr); Leon Portman; > > siprec@ietf.org; > >> Henry.Lum@alcatel-lucent.com > >> Subject: RE: [siprec] Persistent RS session with large set of CS > info > >> > >> John/Ram, > >> > >> As we discussed in the call, there is no need to restrict based on > the > >> number of CS per RS. But there is an need for feedback mechanism (or > >> response code) from SRS to indicate that the maximum limit for > number > >> of m-line or size of metadata is reached. > >> > >> Thanks > >> Partha > >> > >> -----Original Message----- > >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >> Sent: Wednesday, January 26, 2011 9:31 PM > >> To: Ram Mohan R (rmohanr); Leon Portman; Parthasarathi R (partr); > >> siprec@ietf.org; Henry.Lum@alcatel-lucent.com > >> Subject: RE: [siprec] Persistent RS session with large set of CS > info > >> > >> Ram, > >> > >> Yes, I tend to agree about not restricting the number of CSs per RS > on > >> the basis of metadata size, particularly in the light of discussions > > on > >> the call about sending partial metadata. I think other > considerations > >> will deter the use of a single RS for a huge number of parallel CSs > - > > I > >> am thinking of the number of m-lines in the SDP and the fact that > this > >> is only allowed to increase and can never decrease. > >> > >> John (as individual) > >> > >>> -----Original Message----- > >>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >>> Sent: 26 January 2011 13:52 > >>> To: Elwell, John; Leon Portman; Parthasarathi R (partr); > >>> siprec@ietf.org; Henry.Lum@alcatel-lucent.com > >>> Subject: RE: [siprec] Persistent RS session with large set of CS > > info > >>> > >>> My thoughts on this: > >>> > >>> The metadata model and the format allows multiple CS [ any number > of > >>> them] within a single RS. The proposed XML schema of metadata can > >>> accommodate multiple sessions(each with its XML part) and has the > >>> mechanism to distinguish them. > >>> > >>> I do agree that in case we have several CSs [ hundreds on them] the > >>> XML would be huge and we will have to look for ways to compress the > >>> XML body ( which in my opinion should be outside the scope). IMO > > that > >>> is purely implementation specific[ depending on how much each SRC > > can > >>> scale to and also depends on the MTU of that network]. > >>> > >>> As such we should not restrict the number of CSs per RS. Probably > we > >>> should have some guidelines. > >>> > >>> Ram > >>> > >>>> -----Original Message----- > >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>>> Behalf Of Elwell, John > >>>> Sent: Wednesday, January 26, 2011 6:57 PM > >>>> To: Leon Portman; Parthasarathi R (partr); 'siprec@ietf.org'; > >>>> 'Henry.Lum@alcatel-lucent.com' > >>>> Subject: Re: [siprec] Persistent RS session with large set > >>> of CS info > >>>> > >>>> That is a decision we need to make - we would just need to > > consider > >>> the > >>>> implications. For example, as soon as you allow>1 parallel > >>> CS on the > >>>> same RS, you have to decide how to distinguish their > >>> metadatas, e.g., > >>>> multiple body parts, multiple elements in the same XML body > >>> part. Not > >>>> really a problem, just need to figure it out. > >>>> > >>>> John (as individual) > >>>> > >>>>> -----Original Message----- > >>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] > >>>>> Sent: 26 January 2011 12:37 > >>>>> To: 'partr@cisco.com'; Elwell, John; 'siprec@ietf.org'; > >>>>> 'Henry.Lum@alcatel-lucent.com' > >>>>> Subject: Re: Persistent RS session with large set of CS info > >>>>> > >>>>> There was no intent to limit number of m-lines per RS. It is > > more > >>>>> implementation decision to have one giant RS or multiple Rs > >>>>> blocks. > >>>>> > >>>>> Leon > >>>>> > >>>>> > >>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > >>>>> Sent: Wednesday, January 26, 2011 11:34 AM > >>>>> To: Elwell, John; > >>>>> siprec@ietf.org; Leon Portman; Henry Lum > >>>>> > >>>>> Subject: RE: Persistent RS session with large set of CS info > >>>>> > >>>>> > >>>>> John, > >>>>> > >>>>> Please read inline. > >>>>> > >>>>> Thanks > >>>>> Partha > >>>>> > >>>>> ________________________________ > >>>>> > >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>>>> Sent: Wed 1/26/2011 12:54 PM > >>>>> To: Parthasarathi R (partr); siprec@ietf.org; Leon Portman; > > Henry > >>> Lum > >>>>> Subject: RE: Persistent RS session with large set of CS info > >>>>> > >>>>> > >>>>> > >>>>> I tend to agree with Partha's concerns on scalability. > >>>>> Perhaps separate persistent RSs would be preferable, rather than > >> a > >>>>> single persistent RS with a large/huge number of pre-allocated > >>>>> m-lines. A persistent RS supporting more than 1 parallel CS > > might > >>>>> be feasible for a very small number of CSs, as might be > >>>>> encountered at a user's device, so it might be worth retaining > >> the > >>>>> concept. Or we could say that an RS must not support more than > >> one > >>>>> parallel CS, thereby forcing separate RSs for parallel CSs. > >>>>> > >>>>> we will discuss about this solution approach in detail > >>>>> during today's meeting and try to bring the > >>> closure > >>>>> > >>>>> I am not sure I understand the need to bring CS-Group into the > >>>>> solution. Different CSs from the same CS-Group could use the > > same > >>>>> RS or different RSs - it shouldn't matter. > >>>>> > >>>>> > >>>>> Sorry in case I confused. As you mentioned, there is no > >>>>> restriction w.r.t single CSG in single RS or single CSG in > >>>>> multiple RS and it does not matter. I just provided the example > >>>>> wherein each RS may use same CSG. > >>>>> > >>>>> John (as individual) > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: siprec-bounces@ietf.org > >>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi > >>>>> R (partr) > >>>>>> Sent: 26 January 2011 01:03 > >>>>>> To: siprec@ietf.org; Leon Portman; Henry Lum > >>>>>> Subject: [siprec] Persistent RS session with large set > >>> of CS info > >>>>>> > >>>>>> Leon/Henry, > >>>>>> > >>>>>> The proposal of pre-negotiate large of m-lines in case SRC > >>> supports > >>>>>> large number of sessions is not a optimal solution for the > >>>> following > >>>>>> reason: > >>>>>> > >>>>>> 1) Maintaining such a large number of m-line will be an > >>>> architecture > >>>>>> challenge in as SRC would have maintained very few m-line till > >>>>>> recording feature is implemented. Let take 200 session > >>>>>> supported in SRC then 400 m-lines has to be maintained in case > >>>>>> of unmixed recording > >>>>> of audio for > >>>>>> two party call and 800 m-lines in case of recording > >>> unmixed audio > >>> & > >>>>>> video call for two party call. > >>>>>> > >>>>>> 2) As John pointed out in another mail thread, it is > >>> not possible > >>>> to > >>>>>> remove m-line once it is created in persistent RS. > >>>>>> > >>>>>> 3) SRC wastes its resources when the number of recording > >> session > >>> is > >>>>>> lower. In case SRC performs lot more services apart from > >>>>>> recording, huge performance impact will be seen in SRC as the > >>>>>> resources are pre-occupied for persistent RS. > >>>>>> > >>>>>> In the earlier mail, I have proposed to create > >>> pre-allocated pool > >>>> of > >>>>>> persistent RS for SRC which handle large number > >>> sessions. Each RS > >>>> is > >>>>>> associated with one CS group (CSG) whenever CSG is created, RS > >>>>>> is freed from CSG when CSG is terminated and RS is re-used for > >>>>>> another CSG later. > >>>>>> Here, persistent RS allocation/de-allocation is > >>>>>> implementation-dependent and the resource optimization is > >>>>>> possible based on > >>> implementation. > >>>>>> > >>>>>> I agree that pre-negotiated persistent RS works for end-point > >>>>>> which acts as SRC and may work for SRC with few (2-5) > > sessions. > >>>>>> > >>>>>> Please let me know your opinion here. > >>>>>> > >>>>>> Thanks > >>>>>> Partha > >>>>>> > >>>>>> Topic - Protocol (Henry Lum / Leon Portman) > >>>>>> draft-portman-siprec-protocol-02 > >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > >>>>>> Draft: > >>>>> https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ > >>>>>> Slides: > >>>>> http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20- > >>>>>> %20virtual%20interim%20Dec%2016%202010.pdf > >>>>>> > >>>>>> Slide 4 (Persistent recording): Leon pointed out that the > > whole > >>>>>> idea of persistent recording is not to spend time negotiating > >>>>>> m-lines when a CS starts - so he prefers the second option on > >>>>>> the slide. For SRCs > >>>> that > >>>>>> support a large number of parallel CSs, the SRC could > >>>>> pre-negotiate a > >>>>>> large number of m-lines (perhaps based on licensing), > >>> rather like > >>>>>> provisioning trunks. Paul felt that the other option should be > >>>>>> kept open > >>>>>> - a slight delay in negotiating a new m-line could be handled > >> by > >>>>>> transmitting the data slightly delayed, without losing any. > >>>>> Henry also > >>>>>> mentioned the possibility of the offer-answer failing. It was > >>>>>> questioned whether there needs to be something in the protocol > >>>>>> to indicate > >>> the > >>>>>> delay. This issue should be brought to the list. > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From partr@cisco.com Wed Jan 26 16:25:15 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 133773A6A16 for ; Wed, 26 Jan 2011 16:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.899 X-Spam-Level: X-Spam-Status: No, score=-8.899 tagged_above=-999 required=5 tests=[AWL=-0.897, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qf4jiH59DzNW for ; Wed, 26 Jan 2011 16:25:12 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 5BC3C3A6899 for ; Wed, 26 Jan 2011 16:25:12 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4FAN9KQE1AaMHG/2dsb2JhbACcYIc3ZHOhB5tIhU8EhRWKYA Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-3.cisco.com with ESMTP; 27 Jan 2011 00:28:13 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0R0RUfa007162; Thu, 27 Jan 2011 00:28:12 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Jan 2011 05:57:53 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBBDB9.09631B3F" Date: Thu, 27 Jan 2011 05:57:53 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Persistent RS session with large set of CS info Thread-Index: Acu9d/DravbH4eOUQoydRS1yh30XLwAKBcHgAAWNir8= References: <07465C1D981ABC41A344374066AE1A2C389F4A5B6B@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD05124D2C@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05124D4B@XMB-BGL-417.cisco.com> <4D404ECA.1000902@cisco.com> <059AF07365DC474393A19A3AF187DF7406989EA6@NAHALD.us.int.genesyslab.com> From: "Parthasarathi R (partr)" To: "Henry Lum" , "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 27 Jan 2011 00:27:53.0786 (UTC) FILETIME=[0999B9A0:01CBBDB9] Subject: Re: [siprec] Persistent RS session with large set of CS info X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 00:25:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBBDB9.09631B3F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul, =20 I agree with you that 488 with new warning code in the range of 308-329 = will meet the requirement of rejecting too many m-line received in SDP = and warning code has to be generic enough. This warning code *MAY* be = used by other WG like CLUE(telepresence) as multiple m-line handling is = a common issue. =20 413 response shall be used in case size of the metadata is too large. = Please let me know your opinon here. =20 Thanks Partha ________________________________ From: siprec-bounces@ietf.org on behalf of Henry Lum Sent: Thu 1/27/2011 2:59 AM To: Paul Kyzivat (pkyzivat); siprec@ietf.org Subject: Re: [siprec] Persistent RS session with large set of CS info Agreed; I don't think this error should be specific to siprec. Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Wednesday, January 26, 2011 11:42 AM > To: siprec@ietf.org > Subject: Re: [siprec] Persistent RS session with large set of CS info > > > > On 1/26/2011 11:18 AM, Ram Mohan R (rmohanr) wrote: > > Feedback(new response code) from SRS could be one way to do this, but > I > > don't see a need to extend SIP error code for this purpose. > > The other approach is the SRC itself determines the size of the > message > > has reached the threshold [ say based on the MTU of the network it is > > in] and decide to spawn another RS to SRS. We could leave it to the > > implementers and probably just have some guidelines. > > Too many m-lines could be dealt with by a 488 response. (We might need > a > new Warn code.) This error would not be specific to siprec. > > But it would be wise to avoid getting the error. > > Thanks, > Paul > > > Regards, > > Ram > > > >> -----Original Message----- > >> From: Parthasarathi R (partr) > >> Sent: Wednesday, January 26, 2011 9:37 PM > >> To: Elwell, John; Ram Mohan R (rmohanr); Leon Portman; > > siprec@ietf.org; > >> Henry.Lum@alcatel-lucent.com > >> Subject: RE: [siprec] Persistent RS session with large set of CS > info > >> > >> John/Ram, > >> > >> As we discussed in the call, there is no need to restrict based on > the > >> number of CS per RS. But there is an need for feedback mechanism (or > >> response code) from SRS to indicate that the maximum limit for > number > >> of m-line or size of metadata is reached. > >> > >> Thanks > >> Partha > >> > >> -----Original Message----- > >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >> Sent: Wednesday, January 26, 2011 9:31 PM > >> To: Ram Mohan R (rmohanr); Leon Portman; Parthasarathi R (partr); > >> siprec@ietf.org; Henry.Lum@alcatel-lucent.com > >> Subject: RE: [siprec] Persistent RS session with large set of CS > info > >> > >> Ram, > >> > >> Yes, I tend to agree about not restricting the number of CSs per RS > on > >> the basis of metadata size, particularly in the light of discussions > > on > >> the call about sending partial metadata. I think other > considerations > >> will deter the use of a single RS for a huge number of parallel CSs > - > > I > >> am thinking of the number of m-lines in the SDP and the fact that > this > >> is only allowed to increase and can never decrease. > >> > >> John (as individual) > >> > >>> -----Original Message----- > >>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >>> Sent: 26 January 2011 13:52 > >>> To: Elwell, John; Leon Portman; Parthasarathi R (partr); > >>> siprec@ietf.org; Henry.Lum@alcatel-lucent.com > >>> Subject: RE: [siprec] Persistent RS session with large set of CS > > info > >>> > >>> My thoughts on this: > >>> > >>> The metadata model and the format allows multiple CS [ any number > of > >>> them] within a single RS. The proposed XML schema of metadata can > >>> accommodate multiple sessions(each with its XML part) and has the > >>> mechanism to distinguish them. > >>> > >>> I do agree that in case we have several CSs [ hundreds on them] the > >>> XML would be huge and we will have to look for ways to compress the > >>> XML body ( which in my opinion should be outside the scope). IMO > > that > >>> is purely implementation specific[ depending on how much each SRC > > can > >>> scale to and also depends on the MTU of that network]. > >>> > >>> As such we should not restrict the number of CSs per RS. Probably > we > >>> should have some guidelines. > >>> > >>> Ram > >>> > >>>> -----Original Message----- > >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>>> Behalf Of Elwell, John > >>>> Sent: Wednesday, January 26, 2011 6:57 PM > >>>> To: Leon Portman; Parthasarathi R (partr); 'siprec@ietf.org'; > >>>> 'Henry.Lum@alcatel-lucent.com' > >>>> Subject: Re: [siprec] Persistent RS session with large set > >>> of CS info > >>>> > >>>> That is a decision we need to make - we would just need to > > consider > >>> the > >>>> implications. For example, as soon as you allow>1 parallel > >>> CS on the > >>>> same RS, you have to decide how to distinguish their > >>> metadatas, e.g., > >>>> multiple body parts, multiple elements in the same XML body > >>> part. Not > >>>> really a problem, just need to figure it out. > >>>> > >>>> John (as individual) > >>>> > >>>>> -----Original Message----- > >>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] > >>>>> Sent: 26 January 2011 12:37 > >>>>> To: 'partr@cisco.com'; Elwell, John; 'siprec@ietf.org'; > >>>>> 'Henry.Lum@alcatel-lucent.com' > >>>>> Subject: Re: Persistent RS session with large set of CS info > >>>>> > >>>>> There was no intent to limit number of m-lines per RS. It is > > more > >>>>> implementation decision to have one giant RS or multiple Rs > >>>>> blocks. > >>>>> > >>>>> Leon > >>>>> > >>>>> > >>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > >>>>> Sent: Wednesday, January 26, 2011 11:34 AM > >>>>> To: Elwell, John; > >>>>> siprec@ietf.org; Leon Portman; Henry Lum > >>>>> > >>>>> Subject: RE: Persistent RS session with large set of CS info > >>>>> > >>>>> > >>>>> John, > >>>>> > >>>>> Please read inline. > >>>>> > >>>>> Thanks > >>>>> Partha > >>>>> > >>>>> ________________________________ > >>>>> > >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>>>> Sent: Wed 1/26/2011 12:54 PM > >>>>> To: Parthasarathi R (partr); siprec@ietf.org; Leon Portman; > > Henry > >>> Lum > >>>>> Subject: RE: Persistent RS session with large set of CS info > >>>>> > >>>>> > >>>>> > >>>>> I tend to agree with Partha's concerns on scalability. > >>>>> Perhaps separate persistent RSs would be preferable, rather than > >> a > >>>>> single persistent RS with a large/huge number of pre-allocated > >>>>> m-lines. A persistent RS supporting more than 1 parallel CS > > might > >>>>> be feasible for a very small number of CSs, as might be > >>>>> encountered at a user's device, so it might be worth retaining > >> the > >>>>> concept. Or we could say that an RS must not support more than > >> one > >>>>> parallel CS, thereby forcing separate RSs for parallel CSs. > >>>>> > >>>>> we will discuss about this solution approach in detail > >>>>> during today's meeting and try to bring the > >>> closure > >>>>> > >>>>> I am not sure I understand the need to bring CS-Group into the > >>>>> solution. Different CSs from the same CS-Group could use the > > same > >>>>> RS or different RSs - it shouldn't matter. > >>>>> > >>>>> > >>>>> Sorry in case I confused. As you mentioned, there is no > >>>>> restriction w.r.t single CSG in single RS or single CSG in > >>>>> multiple RS and it does not matter. I just provided the example > >>>>> wherein each RS may use same CSG. > >>>>> > >>>>> John (as individual) > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: siprec-bounces@ietf.org > >>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi > >>>>> R (partr) > >>>>>> Sent: 26 January 2011 01:03 > >>>>>> To: siprec@ietf.org; Leon Portman; Henry Lum > >>>>>> Subject: [siprec] Persistent RS session with large set > >>> of CS info > >>>>>> > >>>>>> Leon/Henry, > >>>>>> > >>>>>> The proposal of pre-negotiate large of m-lines in case SRC > >>> supports > >>>>>> large number of sessions is not a optimal solution for the > >>>> following > >>>>>> reason: > >>>>>> > >>>>>> 1) Maintaining such a large number of m-line will be an > >>>> architecture > >>>>>> challenge in as SRC would have maintained very few m-line till > >>>>>> recording feature is implemented. Let take 200 session > >>>>>> supported in SRC then 400 m-lines has to be maintained in case > >>>>>> of unmixed recording > >>>>> of audio for > >>>>>> two party call and 800 m-lines in case of recording > >>> unmixed audio > >>> & > >>>>>> video call for two party call. > >>>>>> > >>>>>> 2) As John pointed out in another mail thread, it is > >>> not possible > >>>> to > >>>>>> remove m-line once it is created in persistent RS. > >>>>>> > >>>>>> 3) SRC wastes its resources when the number of recording > >> session > >>> is > >>>>>> lower. In case SRC performs lot more services apart from > >>>>>> recording, huge performance impact will be seen in SRC as the > >>>>>> resources are pre-occupied for persistent RS. > >>>>>> > >>>>>> In the earlier mail, I have proposed to create > >>> pre-allocated pool > >>>> of > >>>>>> persistent RS for SRC which handle large number > >>> sessions. Each RS > >>>> is > >>>>>> associated with one CS group (CSG) whenever CSG is created, RS > >>>>>> is freed from CSG when CSG is terminated and RS is re-used for > >>>>>> another CSG later. > >>>>>> Here, persistent RS allocation/de-allocation is > >>>>>> implementation-dependent and the resource optimization is > >>>>>> possible based on > >>> implementation. > >>>>>> > >>>>>> I agree that pre-negotiated persistent RS works for end-point > >>>>>> which acts as SRC and may work for SRC with few (2-5) > > sessions. > >>>>>> > >>>>>> Please let me know your opinion here. > >>>>>> > >>>>>> Thanks > >>>>>> Partha > >>>>>> > >>>>>> Topic - Protocol (Henry Lum / Leon Portman) > >>>>>> draft-portman-siprec-protocol-02 > >>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>> Draft: > >>>>> https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ > >>>>>> Slides: > >>>>> http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20- > >>>>>> %20virtual%20interim%20Dec%2016%202010.pdf > >>>>>> > >>>>>> Slide 4 (Persistent recording): Leon pointed out that the > > whole > >>>>>> idea of persistent recording is not to spend time negotiating > >>>>>> m-lines when a CS starts - so he prefers the second option on > >>>>>> the slide. For SRCs > >>>> that > >>>>>> support a large number of parallel CSs, the SRC could > >>>>> pre-negotiate a > >>>>>> large number of m-lines (perhaps based on licensing), > >>> rather like > >>>>>> provisioning trunks. Paul felt that the other option should be > >>>>>> kept open > >>>>>> - a slight delay in negotiating a new m-line could be handled > >> by > >>>>>> transmitting the data slightly delayed, without losing any. > >>>>> Henry also > >>>>>> mentioned the possibility of the offer-answer failing. It was > >>>>>> questioned whether there needs to be something in the protocol > >>>>>> to indicate > >>> the > >>>>>> delay. This issue should be brought to the list. > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec =20 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain = confidential and proprietary information of Alcatel-Lucent and/or its = affiliated entities. Access by the intended recipient only is = authorized. Any liability arising from any party acting, or refraining = from acting, on any information contained in this e-mail is hereby = excluded. If you are not the intended recipient, please notify the = sender immediately, destroy the original transmission and its = attachments and do not disclose the contents to any other person, use it = for any purpose, or store or copy the information in any medium. = Copyright in this e-mail and any attachments belongs to Alcatel-Lucent = and/or its affiliated entities. =20 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec ------_=_NextPart_001_01CBBDB9.09631B3F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [siprec] Persistent RS session with = large set of CS info=0A= =0A= =0A= =0A=
=0A=
Paul,
=0A=
 
=0A=
I agree with you = that 488 with new warning code in the range of 308-329 will meet = the requirement of rejecting too many m-line received in = SDP and warning code has to be generic enough. This warning = code *MAY* be used by other WG like CLUE(telepresence) as multiple = m-line handling is a common issue.
=0A=
 
=0A=
413 response shall be used in = case size of the metadata is too large. Please let me know your opinon = here.
=0A=
 
=0A=
Thanks
=0A=
Partha
=0A=

=0A=
=0A= From: siprec-bounces@ietf.org on = behalf of Henry Lum
Sent: Thu 1/27/2011 2:59 AM
To: = Paul Kyzivat (pkyzivat); siprec@ietf.org
Subject: Re: [siprec] = Persistent RS session with large set of CS info

=0A=
=0A=

Agreed; I don't think this error should be specific to = siprec.

Henry

> -----Original Message-----
> = From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On
> Behalf Of Paul Kyzivat
> Sent: Wednesday, January = 26, 2011 11:42 AM
> To: siprec@ietf.org
> Subject: Re: = [siprec] Persistent RS session with large set of CS = info
>
>
>
> On 1/26/2011 11:18 AM, Ram Mohan R = (rmohanr) wrote:
> > Feedback(new response code) from SRS could = be one way to do this,
but
> I
> > don't see a need to = extend SIP error code for this purpose.
> > The other approach = is the SRC itself determines the size of the
> message
> = > has reached the threshold [ say based on the MTU of the network = it
is
> > in] and decide to spawn another RS to SRS. We = could leave it to the
> > implementers and probably just have = some guidelines.
>
> Too many m-lines could be dealt with by = a 488 response. (We might need
> a
> new Warn code.) This = error would not be specific to siprec.
>
> But it would be = wise to avoid getting the error.
>
> =       Thanks,
> =       Paul
>
> > = Regards,
> > Ram
> >
> >> -----Original = Message-----
> >> From: Parthasarathi R (partr)
> = >> Sent: Wednesday, January 26, 2011 9:37 PM
> >> To: = Elwell, John; Ram Mohan R (rmohanr); Leon Portman;
> > = siprec@ietf.org;
> >> Henry.Lum@alcatel-lucent.com
> = >> Subject: RE: [siprec] Persistent RS session with large set of = CS
> info
> >>
> >> John/Ram,
> = >>
> >> As we discussed in the call, there is no need = to restrict based on
> the
> >> number of CS per RS. = But there is an need for feedback mechanism
(or
> >> = response code) from SRS to indicate that the maximum limit for
> = number
> >> of m-line or size of metadata is = reached.
> >>
> >> Thanks
> >> = Partha
> >>
> >> -----Original = Message-----
> >> From: Elwell, John [mailto:john.elwell@sie= mens-enterprise.com]
> >> Sent: Wednesday, January 26, = 2011 9:31 PM
> >> To: Ram Mohan R (rmohanr); Leon Portman; = Parthasarathi R (partr);
> >> siprec@ietf.org; = Henry.Lum@alcatel-lucent.com
> >> Subject: RE: [siprec] = Persistent RS session with large set of CS
> info
> = >>
> >> Ram,
> >>
> >> Yes, I = tend to agree about not restricting the number of CSs per RS
> = on
> >> the basis of metadata size, particularly in the = light of
discussions
> > on
> >> the call about = sending partial metadata. I think other
> considerations
> = >> will deter the use of a single RS for a huge number of parallel = CSs
> -
> > I
> >> am thinking of the number = of m-lines in the SDP and the fact that
> this
> >> is = only allowed to increase and can never decrease.
> = >>
> >> John (as individual)
> >>
> = >>> -----Original Message-----
> >>> From: Ram = Mohan R (rmohanr) [mailto:rmohanr@cisco.com]
> = >>> Sent: 26 January 2011 13:52
> >>> To: = Elwell, John; Leon Portman; Parthasarathi R (partr);
> = >>> siprec@ietf.org; Henry.Lum@alcatel-lucent.com
> = >>> Subject: RE: [siprec] Persistent RS session with large set = of CS
> > info
> >>>
> >>> My = thoughts on this:
> >>>
> >>> The metadata = model and the format allows multiple CS [ any number
> of
> = >>> them] within a single RS. The proposed XML schema of = metadata can
> >>> accommodate multiple sessions(each = with its XML part) and has the
> >>> mechanism to = distinguish them.
> >>>
> >>> I do agree = that in case we have several CSs [ hundreds on them]
the
> = >>> XML would be huge and we will have to look for ways to = compress
the
> >>> XML body ( which in my opinion = should be outside the scope). IMO
> > that
> >>> = is purely implementation specific[ depending on how much each = SRC
> > can
> >>> scale to and also depends on = the MTU of that network].
> >>>
> >>> As = such we should not restrict the number of CSs per RS. Probably
> = we
> >>> should have some guidelines.
> = >>>
> >>> Ram
> >>>
> = >>>> -----Original Message-----
> >>>> = From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On
> >>>> Behalf Of Elwell, John
> = >>>> Sent: Wednesday, January 26, 2011 6:57 PM
> = >>>> To: Leon Portman; Parthasarathi R (partr); = 'siprec@ietf.org';
> >>>> = 'Henry.Lum@alcatel-lucent.com'
> >>>> Subject: Re: = [siprec] Persistent RS session with large set
> >>> of CS = info
> >>>>
> >>>> That is a = decision we need to make - we would just need to
> > = consider
> >>> the
> >>>> implications. = For example, as soon as you allow>1 parallel
> >>> CS = on the
> >>>> same RS, you have to decide how to = distinguish their
> >>> metadatas, e.g.,
> = >>>> multiple body parts, multiple elements in the same XML = body
> >>> part. Not
> >>>> really a = problem, just need to figure it out.
> >>>>
> = >>>> John (as individual)
> >>>>
> = >>>>> -----Original Message-----
> = >>>>> From: Leon Portman [mailto:Leon.Portman@nice.com]> >>>>> Sent: 26 January 2011 12:37
> = >>>>> To: 'partr@cisco.com'; Elwell, John; = 'siprec@ietf.org';
> >>>>> = 'Henry.Lum@alcatel-lucent.com'
> >>>>> Subject: Re: = Persistent RS session with large set of CS info
> = >>>>>
> >>>>> There was no intent to = limit number of m-lines per RS. It is
> > more
> = >>>>> implementation decision to have one giant RS or = multiple Rs
> >>>>> blocks.
> = >>>>>
> >>>>> Leon
> = >>>>>
> >>>>>
> = >>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com]
> = >>>>> Sent: Wednesday, January 26, 2011 11:34 AM
> = >>>>> To: Elwell, = John<john.elwell@siemens-enterprise.com>;
> = >>>>> siprec@ietf.org<siprec@ietf.org>; Leon = Portman; Henry Lum
> >>>>> = <Henry.Lum@alcatel-lucent.com>
> >>>>> = Subject: RE: Persistent RS session with large set of CS info
> = >>>>>
> >>>>>
> = >>>>> John,
> >>>>>
> = >>>>> Please read inline.
> = >>>>>
> >>>>> Thanks
> = >>>>> Partha
> >>>>>
> = >>>>> ________________________________
> = >>>>>
> >>>>> From: Elwell, John [mailto:john.elwell@sie= mens-enterprise.com]
> >>>>> Sent: Wed = 1/26/2011 12:54 PM
> >>>>> To: Parthasarathi R = (partr); siprec@ietf.org; Leon Portman;
> > Henry
> = >>> Lum
> >>>>> Subject: RE: Persistent RS = session with large set of CS info
> >>>>>
> = >>>>>
> >>>>>
> = >>>>> I tend to agree with Partha's concerns on = scalability.
> >>>>> Perhaps separate persistent = RSs would be preferable, rather than
> >> a
> = >>>>> single persistent RS with a large/huge number of = pre-allocated
> >>>>> m-lines. A persistent RS = supporting more than 1 parallel CS
> > might
> = >>>>> be feasible for a very small number of CSs, as = might be
> >>>>> encountered at a user's device, so = it might be worth retaining
> >> the
> = >>>>> concept. Or we could say that an RS must not = support more than
> >> one
> >>>>> = parallel CS, thereby forcing separate RSs for parallel CSs.
> = >>>>>
> >>>>> <Partha>  = we will discuss about this solution approach in detail
> = >>>>> during today's meeting and try to bring the
> = >>> closure</Partha>
> >>>>>
> = >>>>> I am not sure I understand the need to bring = CS-Group into the
> >>>>> solution. Different CSs = from the same CS-Group could use the
> > same
> = >>>>> RS or different RSs - it shouldn't matter.
> = >>>>>
> >>>>>
> = >>>>> <Partha>  Sorry in case I confused. As = you mentioned, there is
no
> >>>>> restriction = w.r.t single CSG in single RS or single CSG in
> = >>>>> multiple RS and it does not matter. I just provided = the example
> >>>>> wherein each RS may use same = CSG.</Partha>
> >>>>>
> = >>>>> John (as individual)
> = >>>>>
> >>>>>> -----Original = Message-----
> >>>>>> From: = siprec-bounces@ietf.org
> >>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi
> >>>>> R = (partr)
> >>>>>> Sent: 26 January 2011 = 01:03
> >>>>>> To: siprec@ietf.org; Leon = Portman; Henry Lum
> >>>>>> Subject: [siprec] = Persistent RS session with large set
> >>> of CS = info
> >>>>>>
> >>>>>> = Leon/Henry,
> >>>>>>
> = >>>>>> The proposal of pre-negotiate large of m-lines = in case SRC
> >>> supports
> = >>>>>> large number of sessions is not a optimal = solution for the
> >>>> following
> = >>>>>> reason:
> = >>>>>>
> >>>>>> 1) Maintaining = such a large number of m-line will be an
> >>>> = architecture
> >>>>>> challenge in as SRC would = have maintained very few m-line till
> >>>>>> = recording feature is implemented. Let take  200 session
> = >>>>>> supported in SRC then 400 m-lines has to be = maintained in case
> >>>>>> of unmixed = recording
> >>>>> of audio for
> = >>>>>> two party call and 800 m-lines in case of = recording
> >>> unmixed audio
> >>> = &
> >>>>>> video call for two party = call.
> >>>>>>
> >>>>>> = 2) As John pointed out in another mail thread, it is
> = >>> not possible
> >>>> to
> = >>>>>> remove m-line once it is created in persistent = RS.
> >>>>>>
> >>>>>> 3) = SRC wastes its resources when the number of recording
> >> = session
> >>> is
> >>>>>> lower. = In case SRC performs lot more services apart from
> = >>>>>> recording, huge performance impact will be seen = in SRC as the
> >>>>>> resources are = pre-occupied for persistent RS.
> >>>>>>
> = >>>>>> In the earlier mail, I have proposed to = create
> >>> pre-allocated pool
> >>>> = of
> >>>>>> persistent RS for SRC which handle = large number
> >>> sessions. Each RS
> = >>>> is
> >>>>>> associated with one = CS group (CSG) whenever CSG is created, RS
> = >>>>>> is freed from CSG when CSG is terminated and RS = is re-used for
> >>>>>> another CSG = later.
> >>>>>> Here, persistent RS = allocation/de-allocation is
> >>>>>> = implementation-dependent and the resource optimization is
> = >>>>>> possible based on
> >>> = implementation.
> >>>>>>
> = >>>>>> I agree that pre-negotiated persistent RS works = for end-point
> >>>>>> which acts as SRC and may = work for SRC with few (2-5)
> > sessions.
> = >>>>>>
> >>>>>> Please let me = know your opinion here.
> >>>>>>
> = >>>>>> Thanks
> >>>>>> = Partha
> >>>>>>
> >>>>>> = Topic - Protocol (Henry Lum / Leon Portman)
> = >>>>>> draft-portman-siprec-protocol-02
> = >>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
= > >>>>>> Draft:
> >>>>> = https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/
&g= t; >>>>>> Slides:
> >>>>> h= ttp://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20-
>= >>>>>> = %20virtual%20interim%20Dec%2016%202010.pdf
> = >>>>>>
> >>>>>> Slide 4 = (Persistent recording): Leon pointed out that the
> > = whole
> >>>>>> idea of persistent recording is = not to spend time negotiating
> >>>>>> m-lines = when a CS starts - so he prefers the second option on
> = >>>>>> the slide. For SRCs
> >>>> = that
> >>>>>> support a large number of parallel = CSs, the SRC could
> >>>>> pre-negotiate a
> = >>>>>> large number of m-lines (perhaps based on = licensing),
> >>> rather like
> = >>>>>> provisioning trunks. Paul felt that the other = option should be
> >>>>>> kept open
> = >>>>>> - a slight delay in negotiating a new m-line = could be handled
> >> by
> >>>>>> = transmitting the data slightly delayed, without losing any.
> = >>>>> Henry also
> >>>>>> = mentioned the possibility of the offer-answer failing. It was
> = >>>>>> questioned whether there needs to be something = in the protocol
> >>>>>> to indicate
> = >>> the
> >>>>>> delay. This issue = should be brought to the list.
> >>>>>>
> = >>>>>> = _______________________________________________
> = >>>>>> siprec mailing list
> = >>>>>> siprec@ietf.org
> = >>>>>> https://www.ietf.or= g/mailman/listinfo/siprec
> >>>>>>
> = >>>>>
> >>>>>
> = >>>>>
> >>>> = _______________________________________________
> >>>> = siprec mailing list
> >>>> siprec@ietf.org
> = >>>> https://www.ietf.or= g/mailman/listinfo/siprec
> >>>
> > = _______________________________________________
> > siprec = mailing list
> > siprec@ietf.org
> > https://www.ietf.or= g/mailman/listinfo/siprec
> >
> = _______________________________________________
> siprec mailing = list
> siprec@ietf.org
> https://www.ietf.or= g/mailman/listinfo/siprec

      =           =         =         =        
---------------------------= -------------------------------------------------------------------------= ---------------
CONFIDENTIALITY NOTICE: This e-mail and any files = attached may contain confidential and proprietary information of = Alcatel-Lucent and/or its affiliated entities. Access by the intended = recipient only is authorized. Any liability arising from any party = acting, or refraining from acting, on any information contained in this = e-mail is hereby excluded. If you are not the intended recipient, please = notify the sender immediately, destroy the original transmission and its = attachments and do not disclose the contents to any other person, use it = for any purpose, or store or copy the information in any medium. = Copyright in this e-mail and any attachments belongs to Alcatel-Lucent = and/or its affiliated = entities.
        =         =         =         =        
___________________________= ____________________
siprec mailing list
siprec@ietf.org
https://www.ietf.or= g/mailman/listinfo/siprec

------_=_NextPart_001_01CBBDB9.09631B3F-- From pkyzivat@cisco.com Wed Jan 26 20:03:34 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80DF628C0F3 for ; Wed, 26 Jan 2011 20:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.887 X-Spam-Level: X-Spam-Status: No, score=-109.887 tagged_above=-999 required=5 tests=[AWL=-0.488, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxjLI1hRe-dG for ; Wed, 26 Jan 2011 20:03:32 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 05D353A68E5 for ; Wed, 26 Jan 2011 20:03:31 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 27 Jan 2011 04:06:34 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0R46XRE022545; Thu, 27 Jan 2011 04:06:33 GMT Message-ID: <4D40EF4A.9030402@cisco.com> Date: Wed, 26 Jan 2011 23:06:34 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Parthasarathi R (partr)" References: <07465C1D981ABC41A344374066AE1A2C389F4A5B6B@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD05124D2C@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05124D4B@XMB-BGL-417.cisco.com> <4D404ECA.1000902@cisco.com> <059AF07365DC474393A19A3AF187DF7406989EA6@NAHALD.us.int.genesyslab.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org, Henry Lum Subject: Re: [siprec] Persistent RS session with large set of CS info X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 04:03:34 -0000 I'm not certain about the 413 - I just haven't thought about it. Might be fine, or maybe something else is better. On 1/26/2011 7:27 PM, Parthasarathi R (partr) wrote: > Paul, > I agree with you that 488 with new warning code in the range of 308-329 > will meet the requirement of rejecting too many m-line received in SDP > and warning code has to be generic enough. This warning code *MAY* be > used by other WG like CLUE(telepresence) as multiple m-line handling is > a common issue. > 413 response shall be used in case size of the metadata is too large. > Please let me know your opinon here. > Thanks > Partha > > ------------------------------------------------------------------------ > *From:* siprec-bounces@ietf.org on behalf of Henry Lum > *Sent:* Thu 1/27/2011 2:59 AM > *To:* Paul Kyzivat (pkyzivat); siprec@ietf.org > *Subject:* Re: [siprec] Persistent RS session with large set of CS info > > Agreed; I don't think this error should be specific to siprec. > > Henry > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > Sent: Wednesday, January 26, 2011 11:42 AM > > To: siprec@ietf.org > > Subject: Re: [siprec] Persistent RS session with large set of CS info > > > > > > > > On 1/26/2011 11:18 AM, Ram Mohan R (rmohanr) wrote: > > > Feedback(new response code) from SRS could be one way to do this, > but > > I > > > don't see a need to extend SIP error code for this purpose. > > > The other approach is the SRC itself determines the size of the > > message > > > has reached the threshold [ say based on the MTU of the network it > is > > > in] and decide to spawn another RS to SRS. We could leave it to the > > > implementers and probably just have some guidelines. > > > > Too many m-lines could be dealt with by a 488 response. (We might need > > a > > new Warn code.) This error would not be specific to siprec. > > > > But it would be wise to avoid getting the error. > > > > Thanks, > > Paul > > > > > Regards, > > > Ram > > > > > >> -----Original Message----- > > >> From: Parthasarathi R (partr) > > >> Sent: Wednesday, January 26, 2011 9:37 PM > > >> To: Elwell, John; Ram Mohan R (rmohanr); Leon Portman; > > > siprec@ietf.org; > > >> Henry.Lum@alcatel-lucent.com > > >> Subject: RE: [siprec] Persistent RS session with large set of CS > > info > > >> > > >> John/Ram, > > >> > > >> As we discussed in the call, there is no need to restrict based on > > the > > >> number of CS per RS. But there is an need for feedback mechanism > (or > > >> response code) from SRS to indicate that the maximum limit for > > number > > >> of m-line or size of metadata is reached. > > >> > > >> Thanks > > >> Partha > > >> > > >> -----Original Message----- > > >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > >> Sent: Wednesday, January 26, 2011 9:31 PM > > >> To: Ram Mohan R (rmohanr); Leon Portman; Parthasarathi R (partr); > > >> siprec@ietf.org; Henry.Lum@alcatel-lucent.com > > >> Subject: RE: [siprec] Persistent RS session with large set of CS > > info > > >> > > >> Ram, > > >> > > >> Yes, I tend to agree about not restricting the number of CSs per RS > > on > > >> the basis of metadata size, particularly in the light of > discussions > > > on > > >> the call about sending partial metadata. I think other > > considerations > > >> will deter the use of a single RS for a huge number of parallel CSs > > - > > > I > > >> am thinking of the number of m-lines in the SDP and the fact that > > this > > >> is only allowed to increase and can never decrease. > > >> > > >> John (as individual) > > >> > > >>> -----Original Message----- > > >>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > >>> Sent: 26 January 2011 13:52 > > >>> To: Elwell, John; Leon Portman; Parthasarathi R (partr); > > >>> siprec@ietf.org; Henry.Lum@alcatel-lucent.com > > >>> Subject: RE: [siprec] Persistent RS session with large set of CS > > > info > > >>> > > >>> My thoughts on this: > > >>> > > >>> The metadata model and the format allows multiple CS [ any number > > of > > >>> them] within a single RS. The proposed XML schema of metadata can > > >>> accommodate multiple sessions(each with its XML part) and has the > > >>> mechanism to distinguish them. > > >>> > > >>> I do agree that in case we have several CSs [ hundreds on them] > the > > >>> XML would be huge and we will have to look for ways to compress > the > > >>> XML body ( which in my opinion should be outside the scope). IMO > > > that > > >>> is purely implementation specific[ depending on how much each SRC > > > can > > >>> scale to and also depends on the MTU of that network]. > > >>> > > >>> As such we should not restrict the number of CSs per RS. Probably > > we > > >>> should have some guidelines. > > >>> > > >>> Ram > > >>> > > >>>> -----Original Message----- > > >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > >>>> Behalf Of Elwell, John > > >>>> Sent: Wednesday, January 26, 2011 6:57 PM > > >>>> To: Leon Portman; Parthasarathi R (partr); 'siprec@ietf.org'; > > >>>> 'Henry.Lum@alcatel-lucent.com' > > >>>> Subject: Re: [siprec] Persistent RS session with large set > > >>> of CS info > > >>>> > > >>>> That is a decision we need to make - we would just need to > > > consider > > >>> the > > >>>> implications. For example, as soon as you allow>1 parallel > > >>> CS on the > > >>>> same RS, you have to decide how to distinguish their > > >>> metadatas, e.g., > > >>>> multiple body parts, multiple elements in the same XML body > > >>> part. Not > > >>>> really a problem, just need to figure it out. > > >>>> > > >>>> John (as individual) > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] > > >>>>> Sent: 26 January 2011 12:37 > > >>>>> To: 'partr@cisco.com'; Elwell, John; 'siprec@ietf.org'; > > >>>>> 'Henry.Lum@alcatel-lucent.com' > > >>>>> Subject: Re: Persistent RS session with large set of CS info > > >>>>> > > >>>>> There was no intent to limit number of m-lines per RS. It is > > > more > > >>>>> implementation decision to have one giant RS or multiple Rs > > >>>>> blocks. > > >>>>> > > >>>>> Leon > > >>>>> > > >>>>> > > >>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > >>>>> Sent: Wednesday, January 26, 2011 11:34 AM > > >>>>> To: Elwell, John; > > >>>>> siprec@ietf.org; Leon Portman; Henry Lum > > >>>>> > > >>>>> Subject: RE: Persistent RS session with large set of CS info > > >>>>> > > >>>>> > > >>>>> John, > > >>>>> > > >>>>> Please read inline. > > >>>>> > > >>>>> Thanks > > >>>>> Partha > > >>>>> > > >>>>> ________________________________ > > >>>>> > > >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > >>>>> Sent: Wed 1/26/2011 12:54 PM > > >>>>> To: Parthasarathi R (partr); siprec@ietf.org; Leon Portman; > > > Henry > > >>> Lum > > >>>>> Subject: RE: Persistent RS session with large set of CS info > > >>>>> > > >>>>> > > >>>>> > > >>>>> I tend to agree with Partha's concerns on scalability. > > >>>>> Perhaps separate persistent RSs would be preferable, rather than > > >> a > > >>>>> single persistent RS with a large/huge number of pre-allocated > > >>>>> m-lines. A persistent RS supporting more than 1 parallel CS > > > might > > >>>>> be feasible for a very small number of CSs, as might be > > >>>>> encountered at a user's device, so it might be worth retaining > > >> the > > >>>>> concept. Or we could say that an RS must not support more than > > >> one > > >>>>> parallel CS, thereby forcing separate RSs for parallel CSs. > > >>>>> > > >>>>> we will discuss about this solution approach in detail > > >>>>> during today's meeting and try to bring the > > >>> closure > > >>>>> > > >>>>> I am not sure I understand the need to bring CS-Group into the > > >>>>> solution. Different CSs from the same CS-Group could use the > > > same > > >>>>> RS or different RSs - it shouldn't matter. > > >>>>> > > >>>>> > > >>>>> Sorry in case I confused. As you mentioned, there is > no > > >>>>> restriction w.r.t single CSG in single RS or single CSG in > > >>>>> multiple RS and it does not matter. I just provided the example > > >>>>> wherein each RS may use same CSG. > > >>>>> > > >>>>> John (as individual) > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: siprec-bounces@ietf.org > > >>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi > > >>>>> R (partr) > > >>>>>> Sent: 26 January 2011 01:03 > > >>>>>> To: siprec@ietf.org; Leon Portman; Henry Lum > > >>>>>> Subject: [siprec] Persistent RS session with large set > > >>> of CS info > > >>>>>> > > >>>>>> Leon/Henry, > > >>>>>> > > >>>>>> The proposal of pre-negotiate large of m-lines in case SRC > > >>> supports > > >>>>>> large number of sessions is not a optimal solution for the > > >>>> following > > >>>>>> reason: > > >>>>>> > > >>>>>> 1) Maintaining such a large number of m-line will be an > > >>>> architecture > > >>>>>> challenge in as SRC would have maintained very few m-line till > > >>>>>> recording feature is implemented. Let take 200 session > > >>>>>> supported in SRC then 400 m-lines has to be maintained in case > > >>>>>> of unmixed recording > > >>>>> of audio for > > >>>>>> two party call and 800 m-lines in case of recording > > >>> unmixed audio > > >>> & > > >>>>>> video call for two party call. > > >>>>>> > > >>>>>> 2) As John pointed out in another mail thread, it is > > >>> not possible > > >>>> to > > >>>>>> remove m-line once it is created in persistent RS. > > >>>>>> > > >>>>>> 3) SRC wastes its resources when the number of recording > > >> session > > >>> is > > >>>>>> lower. In case SRC performs lot more services apart from > > >>>>>> recording, huge performance impact will be seen in SRC as the > > >>>>>> resources are pre-occupied for persistent RS. > > >>>>>> > > >>>>>> In the earlier mail, I have proposed to create > > >>> pre-allocated pool > > >>>> of > > >>>>>> persistent RS for SRC which handle large number > > >>> sessions. Each RS > > >>>> is > > >>>>>> associated with one CS group (CSG) whenever CSG is created, RS > > >>>>>> is freed from CSG when CSG is terminated and RS is re-used for > > >>>>>> another CSG later. > > >>>>>> Here, persistent RS allocation/de-allocation is > > >>>>>> implementation-dependent and the resource optimization is > > >>>>>> possible based on > > >>> implementation. > > >>>>>> > > >>>>>> I agree that pre-negotiated persistent RS works for end-point > > >>>>>> which acts as SRC and may work for SRC with few (2-5) > > > sessions. > > >>>>>> > > >>>>>> Please let me know your opinion here. > > >>>>>> > > >>>>>> Thanks > > >>>>>> Partha > > >>>>>> > > >>>>>> Topic - Protocol (Henry Lum / Leon Portman) > > >>>>>> draft-portman-siprec-protocol-02 > > >>>>>> ================================================ > > >>>>>> Draft: > > >>>>> https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ > > >>>>>> Slides: > > >>>>> http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20- > > >>>>>> %20virtual%20interim%20Dec%2016%202010.pdf > > >>>>>> > > >>>>>> Slide 4 (Persistent recording): Leon pointed out that the > > > whole > > >>>>>> idea of persistent recording is not to spend time negotiating > > >>>>>> m-lines when a CS starts - so he prefers the second option on > > >>>>>> the slide. For SRCs > > >>>> that > > >>>>>> support a large number of parallel CSs, the SRC could > > >>>>> pre-negotiate a > > >>>>>> large number of m-lines (perhaps based on licensing), > > >>> rather like > > >>>>>> provisioning trunks. Paul felt that the other option should be > > >>>>>> kept open > > >>>>>> - a slight delay in negotiating a new m-line could be handled > > >> by > > >>>>>> transmitting the data slightly delayed, without losing any. > > >>>>> Henry also > > >>>>>> mentioned the possibility of the offer-answer failing. It was > > >>>>>> questioned whether there needs to be something in the protocol > > >>>>>> to indicate > > >>> the > > >>>>>> delay. This issue should be brought to the list. > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> 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 > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > > ------------------------------------------------------------------------------------------------------------------- > CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain > confidential and proprietary information of Alcatel-Lucent and/or its > affiliated entities. Access by the intended recipient only is > authorized. Any liability arising from any party acting, or refraining > from acting, on any information contained in this e-mail is hereby > excluded. If you are not the intended recipient, please notify the > sender immediately, destroy the original transmission and its > attachments and do not disclose the contents to any other person, use it > for any purpose, or store or copy the information in any medium. > Copyright in this e-mail and any attachments belongs to Alcatel-Lucent > and/or its affiliated entities. > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From john.elwell@siemens-enterprise.com Wed Jan 26 23:00:52 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77E883A6B01 for ; Wed, 26 Jan 2011 23:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXBPP6BOWRjK for ; Wed, 26 Jan 2011 23:00:49 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 14F603A6AF1 for ; Wed, 26 Jan 2011 23:00:48 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3162597; Thu, 27 Jan 2011 08:03:50 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 2BFB423F028E; Thu, 27 Jan 2011 08:03:50 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 27 Jan 2011 08:03:50 +0100 From: "Elwell, John" To: Dave Smith , "siprec@ietf.org" Date: Thu, 27 Jan 2011 08:03:47 +0100 Thread-Topic: Proposed change to REQ-017 concerning cancellation Thread-Index: Acu83pcEUtR/mjUXQMit9DldGQtWeQAuoXcwABXECSA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 07:00:52 -0000 Just changed the subject line so that people concerned will notice it. John > -----Original Message----- > From: Dave Smith [mailto:Dave.d.Smith@alcatel-lucent.com] > Sent: 26 January 2011 21:22 > To: Elwell, John; siprec@ietf.org > Subject: RE: [siprec] Minutes day 1 > > Hi, > Here is my input to my Action Item related to REQ-015/016 - > to raise on > the list any fresh requirements concerning what CS > participants might be > able to request regarding "canceling" and/or "discarding" recording. > > It seems that REQ-017 already covers the basic idea; however, > REQ-017 is > only valid " prior to the start of recording ". My concern > was for the > mechanism to also work "during" recording. > Therefore, my proposal is to consider to update REQ-017 as follows: > > Currently it reads: > o REQ-017 The mechanism MUST support a means for an authorized > participant involved in a CS to request, prior to the start of > recording, that the CS not be recorded > > Change to: > o REQ-017 The mechanism MUST support a means for an authorized > participant involved in a CS to request, during or prior > to the start > of > recording, that the CS not be recorded > > > Use Case supporting this change: > 1. Customer calls a contact center > 2. Agent answers the phone > 3. Customer starts discussing their issue with the Agent > 4. Customer realizes that the call is being recorded (e.g., > they hear a "beep" tone indicating that the call is currently being > recorded) > 5. Customer decides that they do not want the call to be > recorded > 6. Customer requests that the call not be recorded (e.g., > customer phone application is used to send a signal within the CS that > can be received/interpreted by the SRC) > 7. The SRC stops the recording > Also note the following that could further be done, if an > implementation > desires (no req'ts needed): > Optional: 8. The SRC sends metadata to the SRS indicating that > the Customer requested that the call NOT be recorded > Optional: 9. The SRS uses its internal policy procedures and > decides to delete the recorded audio file from the Customer recording > > > > Let me know your inputs and if this change makes sense. > > > Regards, > Dave > > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf > Of Elwell, John > Sent: Tuesday, January 25, 2011 2:24 PM > To: siprec@ietf.org > Subject: [siprec] Minutes day 1 > > Minutes of the SIPREC WG Interim Virtual Meeting > 2011-01-25, 15.00-17.00 GMT/UTC and > 2011-01-25, 14.00-16.00 GMT/UTC > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Meeting chaired by Brian Rosen and John Elwell. > > Participants (session 1): Brian Rosen, John Elwell, Ken Rehor, Leon > Portman, Henry Lum, Ram > Mohen, Andy Hutton, Alan Johnston, Gonzalo Camarillo, Paul > Kyzivat, Dave > Smith, Parthasarathi, Dan Romascanu, Alissa Cooper, Charles Eckel > > Minutes produced by John Elwell. > > Webex chat: See end of these minutes. Jabber was not used. > > Recording day 1: > https://workgreen.webex.com/workgreen/ldr.php?AT=3Dpb&SP=3DMC&rID=3D > 8263017&rK > ey=3D19329980a044b45b > > Meeting started at 15.02. > > Topic - Administrivia (chairs) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > Slides: http://kenrehor.com/ietf/siprec/IETF79.2/Chairs.pdf > > No changes to published agenda. > > > Topic - Requirements (Ken Rehor) > draft-ietf-siprec-req-06 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > Slides: > http://kenrehor.com/ietf/siprec/IETF79.2/IETF-79.2-SIPREC-Req- 2011-01-25 > .pdf > > Slide 4 - proposal to delete REQ-015/016. It was noted that these > requirements talk about "cancel and discard". After some discussion, > there seemed to be agreement that the "cancel" part was > covered by other > requirements (e.g., you can pause and not resume, effectively > cancelling). So the main issue concerned the "discard" part. It was > noted that previous agreements relating to privacy had reached the > conclusion that the retention of recordings is an issue for > the SRS, and > outside the scope of SIPREC. There was no objection to > deleting the two > requirements. > > Although the main focus of the requirements is on what happens on the > SRC-SRS interface, Dave Smith brought up the question of whether a > participant, whose SIP UA might not be collocated with the SRC, can > request the pausing / stopping of a recording, or even > request deletion > of the recording. This would be a requirement impacting the CS, as > opposed to the RS, and it was noted that none of the solution work has > touched on that (although the earlier draft from Alan > Johnston did have > provision for an indication on the CS signalling path that > recording is > taking place, but this was not brought forward into the > present protocol > draft). Dave was invited to raise on the list any fresh requirements > concerning what CS participants might be able to request. > > Slide 5 - proposed new requirement on multiple media streams for the > same media type. It was observed that REQ-010 was probably intended to > cover this case, and Ken will propose words to enhance REQ-010 to make > it clearer. > > Slide 6 - removal of REQ-021. There was no objection to removal. > > Ken will try to seek resolution of the issues above and then publish > -07, which should be very close to being ready to submit to the IESG. > > > Topic - Metadata model (Ram Mohan) > draft-ram-siprec-metadata-03 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Draft: https://datatracker.ietf.org/doc/draft-ram-siprec-metadata/ > Slides: ???? > > Slide 4: Ram explained why an association between Media Stream and CS > had been introduced, because of the injection of things like music on > hold, leading to a media stream without participant. Charles wondered > why music on hold could not be considered a participant. Ram and Paul > explained there were also conference cases where a participant might > host a conference on his device, but those behind the conferencing > device might not be considered CS participants. Charles asked why the > conference focus could not be considered a participant. Paul explained > that the SRC could obtain, using the conference event > package, a list of > participants from the focus, and those participants would > contribute to > the media stream, but those participants would not be part of the CS - > that would be the role of the focus. Henry thought a mixer might be > considered a participant, but Paul explained that if you can obtain a > roster of people behind the mixer, those might be considered > participants rathe > r than the mixer. So there can be participants in the media that are > not participants in the CS. Charles was worried that some > media streams > might not have any identified participants who are generating the > stream. Paul explained that, assuming the media from the participants > are mixed, you would see one media stream and a list of participants. > One participant might be joined to the CS and the others would not be. > Paul thinks we need to explore some use cases and see how > they would be > represented using this model. So if people have particular use cases, > make them known and we check how they would be represented. Ram will > solicit use cases. Partha also had concerns similar to those > of Charles, > but Charles was beginning to see how the present model might > work if you > can get information about non-CS participants who are > generating a media > stream. Paul pointed out that the model does cater for a participant > that is not part of a CS. Charles was invited to post his > continued conc > erns / scenarios to the list, but Paul thinks the use cases concerned > are already covered by the model. > > Slide 6 (CS Group): Nobody on list had come up with a reason > for having > more than one CSG associated with a single CS, and the conclusion > reached on the list seems to stand. > > Slide 7 (CS): No comments on CS slide, except that forced > deletion is to > be removed in line with the requirements discussion. > > Slide 8 (Participant): Clarified that the multiple AORs are > aliases, in > the sense of P-Asserted-Identity being able to carry aliases. > > Concerning the issue of whether participant role is needed as an > attribute, Leon suggested it could be done in application data, but > asked whether we would then publish some application data dictionary. > Paul suggested that application data is just some additional > XML in some > other namespace, so some other group could get together and define it. > Leon was concerned that without some sort of standardization, > different > vendors would implement it differently. John suggested we > need to decide > what things are needed by 80% of deployments and standardize those in > this group, so if that is the case for participant role, we should > standardize it. Partha wanted to include participant role, even though > there might be some cases where it is not available. Paul pointed out > that we had had considerable list discussion on the difficulties of > figuring out the role: UAC/UAS is transaction specific, > inbound/outbound > is problematic, and incoming/outgoing, whilst it might work in some > cases, it w > ill not always work. Perhaps those focused on call centres > can say what > might/might not work. In conclusion, this has to be taken back to the > list. Without repeating the old arguments, those wanting to include > participant role should indicate what are the likely mechanisms that > might support it. > > Slide 10 (Media Stream): How to model media streams that are not > recorded (rejected by SRS or no capability at SRS). Dave thought was > important that you have some information in the metadata that > there was > media that was available for recording but couldn't be recorded, but > there are two cases: where you don't want to record, or where > because of > a temporary limitation you are unable to record but might > want to record > later. Paul agreed, but was concerned about the details, although that > is very much down to the mechanism, e.g., does the SRC need to keep > offering the stream? > > Partha asked a question on start time and end time. Ram clarified this > is these are start and end times of the CS media. It was pointed out > that we have wall clock time in the metadata, and other times can be > relative. Leon suggested there may be a need to retransmit wall clock > time occasionally, to compensate for drift. > > Henry asked whether media stream reference should be part of the > mechanism rather than an attribute. > > Slide 10 (Application data): Leon agreed with the extensible approach, > based on different namespaces. Paul said that he would be tempted to > stop calling it application data and call it extension data. > John (from > the floor) questioned whether it really is an object, or just > attributes > of other objects. Paul said it was just an artefact of how > the model is > drawn, but in the solution it would just be extensibility data. The > authors will rework this with these comments in mind. > > On next steps, people are asked to review and submit further > comments on > -03, and -04 will be produced in due course, after which we might be > consider adoption as a WG item. In particular, we need closure on the > long discussion of media stream relationships. > > > Topic - Protocol (Henry Lum / Leon Portman) > draft-portman-siprec-protocol-02 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Draft: https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ > Slides: http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20- > %20virtual%20interim%20Dec%2016%202010.pdf > > Slide 4 (Persistent recording): Leon pointed out that the > whole idea of > persistent recording is not to spend time negotiating m-lines > when a CS > starts - so he prefers the second option on the slide. For SRCs that > support a large number of parallel CSs, the SRC could pre-negotiate a > large number of m-lines (perhaps based on licensing), rather like > provisioning trunks. Paul felt that the other option should > be kept open > - a slight delay in negotiating a new m-line could be handled by > transmitting the data slightly delayed, without losing any. Henry also > mentioned the possibility of the offer-answer failing. It was > questioned > whether there needs to be something in the protocol to indicate the > delay. This issue should be brought to the list. > > > Day 1 wrap-up > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > It was agreed that on the second day we will start by completing the > Protocol topic and then do the metadata format topic. > > The meeting was closed at 17.00. > > > Day 1 chat log > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > January 25, 2011 3:19:58 PM from Alissa Cooper > to Everyone: I'm not in a place where I can speak in the audio, but I > think we decided not to have requirements related to what > happens to the > recording after it has been made. > > January 25, 2011 3:30:32 PM from Alissa Cooper > to Everyone: it seems like there are cases where the hints are > valuable even if they aren't always honoured > > January 25, 2011 3:39:51 PM from Alissa Cooper > to Everyone: it's old, I'll take it to the list > > January 25, 2011 4:59:32 PM from Kenneth Rehor > to Everyone: Unfortunately I have to drop off now. TTY tomorrow. > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > > > -------------------------------------------------------------- > ----------------------------------------------------- > CONFIDENTIALITY NOTICE: This e-mail and any files attached > may contain confidential and proprietary information of > Alcatel-Lucent and/or its affiliated entities. Access by the > intended recipient only is authorized. Any liability arising > from any party acting, or refraining from acting, on any > information contained in this e-mail is hereby excluded. If > you are not the intended recipient, please notify the sender > immediately, destroy the original transmission and its > attachments and do not disclose the contents to any other > person, use it for any purpose, or store or copy the > information in any medium. Copyright in this e-mail and any > attachments belongs to Alcatel-Lucent and/or its affiliated entities. > > From Dave.d.Smith@alcatel-lucent.com Wed Jan 26 13:18:45 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 253973A69DA for ; Wed, 26 Jan 2011 13:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0-viOOaFFDA for ; Wed, 26 Jan 2011 13:18:43 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id DF45A3A69D8 for ; Wed, 26 Jan 2011 13:18:42 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p0QLLdQO028820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Jan 2011 15:21:39 -0600 (CST) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [172.22.68.187]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0QLLbvP003926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Jan 2011 15:21:39 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id p0QLLbwD004727; Wed, 26 Jan 2011 13:21:37 -0800 (PST) Received: from SARUMAN.us.int.genesyslab.com ([192.168.20.90]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Jan 2011 13:21:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Jan 2011 13:21:36 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Minutes day 1 Thread-Index: Acu83pcEUtR/mjUXQMit9DldGQtWeQAuoXcw References: From: "Dave Smith" To: "Elwell, John" , X-OriginalArrivalTime: 26 Jan 2011 21:21:37.0188 (UTC) FILETIME=[03D43640:01CBBD9F] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 X-Mailman-Approved-At: Wed, 26 Jan 2011 23:02:46 -0800 Subject: Re: [siprec] Minutes day 1 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 21:19:50 -0000 Hi, Here is my input to my Action Item related to REQ-015/016 - to raise on the list any fresh requirements concerning what CS participants might be able to request regarding "canceling" and/or "discarding" recording. It seems that REQ-017 already covers the basic idea; however, REQ-017 is only valid " prior to the start of recording ". My concern was for the mechanism to also work "during" recording. Therefore, my proposal is to consider to update REQ-017 as follows: =20 Currently it reads: o REQ-017 The mechanism MUST support a means for an authorized participant involved in a CS to request, prior to the start of recording, that the CS not be recorded Change to: o REQ-017 The mechanism MUST support a means for an authorized participant involved in a CS to request, during or prior to the start of recording, that the CS not be recorded Use Case supporting this change: 1. Customer calls a contact center 2. Agent answers the phone 3. Customer starts discussing their issue with the Agent 4. Customer realizes that the call is being recorded (e.g., they hear a "beep" tone indicating that the call is currently being recorded) 5. Customer decides that they do not want the call to be recorded 6. Customer requests that the call not be recorded (e.g., customer phone application is used to send a signal within the CS that can be received/interpreted by the SRC) 7. The SRC stops the recording=20 Also note the following that could further be done, if an implementation desires (no req'ts needed): =20 Optional: 8. The SRC sends metadata to the SRS indicating that the Customer requested that the call NOT be recorded Optional: 9. The SRS uses its internal policy procedures and decides to delete the recorded audio file from the Customer recording Let me know your inputs and if this change makes sense. =20 =20 Regards, Dave -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John Sent: Tuesday, January 25, 2011 2:24 PM To: siprec@ietf.org Subject: [siprec] Minutes day 1 Minutes of the SIPREC WG Interim Virtual Meeting 2011-01-25, 15.00-17.00 GMT/UTC and 2011-01-25, 14.00-16.00 GMT/UTC =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Meeting chaired by Brian Rosen and John Elwell. Participants (session 1): Brian Rosen, John Elwell, Ken Rehor, Leon Portman, Henry Lum, Ram=20 Mohen, Andy Hutton, Alan Johnston, Gonzalo Camarillo, Paul Kyzivat, Dave Smith, Parthasarathi, Dan Romascanu, Alissa Cooper, Charles Eckel Minutes produced by John Elwell. Webex chat: See end of these minutes. Jabber was not used. Recording day 1: https://workgreen.webex.com/workgreen/ldr.php?AT=3Dpb&SP=3DMC&rID=3D82630= 17&rK ey=3D19329980a044b45b=20 Meeting started at 15.02. Topic - Administrivia (chairs) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Slides: http://kenrehor.com/ietf/siprec/IETF79.2/Chairs.pdf No changes to published agenda. Topic - Requirements (Ken Rehor) draft-ietf-siprec-req-06 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-req/ Slides: http://kenrehor.com/ietf/siprec/IETF79.2/IETF-79.2-SIPREC-Req-2011-01-25 =2Epdf Slide 4 - proposal to delete REQ-015/016. It was noted that these requirements talk about "cancel and discard". After some discussion, there seemed to be agreement that the "cancel" part was covered by other requirements (e.g., you can pause and not resume, effectively cancelling). So the main issue concerned the "discard" part. It was noted that previous agreements relating to privacy had reached the conclusion that the retention of recordings is an issue for the SRS, and outside the scope of SIPREC. There was no objection to deleting the two requirements. Although the main focus of the requirements is on what happens on the SRC-SRS interface, Dave Smith brought up the question of whether a participant, whose SIP UA might not be collocated with the SRC, can request the pausing / stopping of a recording, or even request deletion of the recording. This would be a requirement impacting the CS, as opposed to the RS, and it was noted that none of the solution work has touched on that (although the earlier draft from Alan Johnston did have provision for an indication on the CS signalling path that recording is taking place, but this was not brought forward into the present protocol draft). Dave was invited to raise on the list any fresh requirements concerning what CS participants might be able to request. Slide 5 - proposed new requirement on multiple media streams for the same media type. It was observed that REQ-010 was probably intended to cover this case, and Ken will propose words to enhance REQ-010 to make it clearer. Slide 6 - removal of REQ-021. There was no objection to removal. Ken will try to seek resolution of the issues above and then publish -07, which should be very close to being ready to submit to the IESG. Topic - Metadata model (Ram Mohan) draft-ram-siprec-metadata-03 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Draft: https://datatracker.ietf.org/doc/draft-ram-siprec-metadata/ Slides: ???? Slide 4: Ram explained why an association between Media Stream and CS had been introduced, because of the injection of things like music on hold, leading to a media stream without participant. Charles wondered why music on hold could not be considered a participant. Ram and Paul explained there were also conference cases where a participant might host a conference on his device, but those behind the conferencing device might not be considered CS participants. Charles asked why the conference focus could not be considered a participant. Paul explained that the SRC could obtain, using the conference event package, a list of participants from the focus, and those participants would contribute to the media stream, but those participants would not be part of the CS - that would be the role of the focus. Henry thought a mixer might be considered a participant, but Paul explained that if you can obtain a roster of people behind the mixer, those might be considered participants rathe r than the mixer. So there can be participants in the media that are not participants in the CS. Charles was worried that some media streams might not have any identified participants who are generating the stream. Paul explained that, assuming the media from the participants are mixed, you would see one media stream and a list of participants. One participant might be joined to the CS and the others would not be. Paul thinks we need to explore some use cases and see how they would be represented using this model. So if people have particular use cases, make them known and we check how they would be represented. Ram will solicit use cases. Partha also had concerns similar to those of Charles, but Charles was beginning to see how the present model might work if you can get information about non-CS participants who are generating a media stream. Paul pointed out that the model does cater for a participant that is not part of a CS. Charles was invited to post his continued conc erns / scenarios to the list, but Paul thinks the use cases concerned are already covered by the model. Slide 6 (CS Group): Nobody on list had come up with a reason for having more than one CSG associated with a single CS, and the conclusion reached on the list seems to stand. Slide 7 (CS): No comments on CS slide, except that forced deletion is to be removed in line with the requirements discussion. Slide 8 (Participant): Clarified that the multiple AORs are aliases, in the sense of P-Asserted-Identity being able to carry aliases. Concerning the issue of whether participant role is needed as an attribute, Leon suggested it could be done in application data, but asked whether we would then publish some application data dictionary. Paul suggested that application data is just some additional XML in some other namespace, so some other group could get together and define it. Leon was concerned that without some sort of standardization, different vendors would implement it differently. John suggested we need to decide what things are needed by 80% of deployments and standardize those in this group, so if that is the case for participant role, we should standardize it. Partha wanted to include participant role, even though there might be some cases where it is not available. Paul pointed out that we had had considerable list discussion on the difficulties of figuring out the role: UAC/UAS is transaction specific, inbound/outbound is problematic, and incoming/outgoing, whilst it might work in some cases, it w ill not always work. Perhaps those focused on call centres can say what might/might not work. In conclusion, this has to be taken back to the list. Without repeating the old arguments, those wanting to include participant role should indicate what are the likely mechanisms that might support it. Slide 10 (Media Stream): How to model media streams that are not recorded (rejected by SRS or no capability at SRS). Dave thought was important that you have some information in the metadata that there was media that was available for recording but couldn't be recorded, but there are two cases: where you don't want to record, or where because of a temporary limitation you are unable to record but might want to record later. Paul agreed, but was concerned about the details, although that is very much down to the mechanism, e.g., does the SRC need to keep offering the stream? Partha asked a question on start time and end time. Ram clarified this is these are start and end times of the CS media. It was pointed out that we have wall clock time in the metadata, and other times can be relative. Leon suggested there may be a need to retransmit wall clock time occasionally, to compensate for drift. Henry asked whether media stream reference should be part of the mechanism rather than an attribute. Slide 10 (Application data): Leon agreed with the extensible approach, based on different namespaces. Paul said that he would be tempted to stop calling it application data and call it extension data. John (from the floor) questioned whether it really is an object, or just attributes of other objects. Paul said it was just an artefact of how the model is drawn, but in the solution it would just be extensibility data. The authors will rework this with these comments in mind. On next steps, people are asked to review and submit further comments on -03, and -04 will be produced in due course, after which we might be consider adoption as a WG item. In particular, we need closure on the long discussion of media stream relationships. Topic - Protocol (Henry Lum / Leon Portman) draft-portman-siprec-protocol-02 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Draft: https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ Slides: http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20- %20virtual%20interim%20Dec%2016%202010.pdf Slide 4 (Persistent recording): Leon pointed out that the whole idea of persistent recording is not to spend time negotiating m-lines when a CS starts - so he prefers the second option on the slide. For SRCs that support a large number of parallel CSs, the SRC could pre-negotiate a large number of m-lines (perhaps based on licensing), rather like provisioning trunks. Paul felt that the other option should be kept open - a slight delay in negotiating a new m-line could be handled by transmitting the data slightly delayed, without losing any. Henry also mentioned the possibility of the offer-answer failing. It was questioned whether there needs to be something in the protocol to indicate the delay. This issue should be brought to the list. Day 1 wrap-up =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D It was agreed that on the second day we will start by completing the Protocol topic and then do the metadata format topic. The meeting was closed at 17.00. Day 1 chat log =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D January 25, 2011 3:19:58 PM from Alissa Cooper to Everyone: I'm not in a place where I can speak in the audio, but I think we decided not to have requirements related to what happens to the recording after it has been made. January 25, 2011 3:30:32 PM from Alissa Cooper to Everyone: it seems like there are cases where the hints are valuable even if they aren't always honoured January 25, 2011 3:39:51 PM from Alissa Cooper to Everyone: it's old, I'll take it to the list January 25, 2011 4:59:32 PM from Kenneth Rehor to Everyone: Unfortunately I have to drop off now. TTY tomorrow. _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From john.elwell@siemens-enterprise.com Wed Jan 26 23:36:02 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA67E3A693F for ; Wed, 26 Jan 2011 23:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUcsLyKLhZoV for ; Wed, 26 Jan 2011 23:36:02 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id D1F1D3A6933 for ; Wed, 26 Jan 2011 23:36:01 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3161420; Thu, 27 Jan 2011 08:39:03 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 3B8291EB82AB; Thu, 27 Jan 2011 08:39:03 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 27 Jan 2011 08:39:03 +0100 From: "Elwell, John" To: "Charles Eckel (eckelcu)" , "siprec@ietf.org" Date: Thu, 27 Jan 2011 08:39:01 +0100 Thread-Topic: metadata model for participant that is not part of CS Thread-Index: Acu9iqr7ynF7z4Y5QUaRyQBZjCoEsQAaTiAQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] metadata model for participant that is not part of CS X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 07:36:03 -0000 I am starting to see Charles's point. For a participant behind a bridge, yo= u don't really know what media he is contributing or what media he is recei= ving. All you know for certain is that the bridge is a participant. Perhaps= we could assign multiple user identities to a bridge participant, thereby = reflecting users behind the bridge that may or may not be contributing to t= he media the bridge sends and may or may not be recipients of media the bri= dge receives. Note that the model when the SRC is at the bridge, rather than outside the = bridge, is quite different. Also the model where the bridge is switching, r= ather than mixing, might be different. John (as individual)=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu) > Sent: 26 January 2011 18:56 > To: siprec@ietf.org > Subject: [siprec] metadata model for participant that is not=20 > part of CS >=20 > This is to follow up on some questions I raised regarding the metadata > model during the interim meeting Tuesday. > My initial concern was that I thought we were allowing media=20 > streams to > be defined without any participant. I now understand that is not the > case; rather, a media stream is always associated with at least one > participant, but that participant need not necessary be=20 > associated with > the CS. > Now I have some concern about participants that are not part=20 > of the CS. > My concern is that the level of metadata we have for such participants > will be inconsistent at best. If the metadata for a non-CS participant > is incomplete, what do we plan to do?=20 > Also, I believe there was reference to a document that contains the > model and some use cases. Which document is that? >=20 > Thanks, > Charles=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From rmohanr@cisco.com Thu Jan 27 04:32:12 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A13C3A6768 for ; Thu, 27 Jan 2011 04:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.468 X-Spam-Level: X-Spam-Status: No, score=-10.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXur1MDvWOBo for ; Thu, 27 Jan 2011 04:32:10 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 783953A659A for ; Thu, 27 Jan 2011 04:32:10 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEEAAb1QE2Q/khMgWdsb2JhbACWII5bFgEWIiSfdZs4hU8EhRWKXA Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 27 Jan 2011 12:35:13 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p0RCZ9hM008203; Thu, 27 Jan 2011 12:35:12 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Jan 2011 18:05:09 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Jan 2011 18:05:07 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD0512507C@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] metadata model for participant that is not part of CS Thread-Index: Acu9iqr7ynF7z4Y5QUaRyQBZjCoEsQAaTiAQAAqEFKA= References: From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , "Charles Eckel (eckelcu)" , X-OriginalArrivalTime: 27 Jan 2011 12:35:09.0843 (UTC) FILETIME=[A2B79E30:01CBBE1E] Subject: Re: [siprec] metadata model for participant that is not part of CS X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 12:32:12 -0000 Hi Charles/John, In the current model, a media stream is always associated with at least one participant. Here is the snippet of the associations between CS and Participant and Participant and Media Streams taken from the draft https://datatracker.ietf.org/doc/draft-ram-siprec-metadata Section 4.3.2 has the associations between CS and Participant Section 4.4.2 has the associations between media stream and participant The current model allows participants who are not part of CS to be part of the model.=20 A example of such a case is: - participants in a premixed media stream. The SRC may have knowledge of such Participants, yet not have any signaling relationship with them. This might arise if one participant in CS is a conf focus. In those case, if the metadata for non-CS participants is incomplete, the SRC can use other mechanisms like subscribing to conference event package to retrieve the information about non-CS participants. To summarize the model allows representing of non-CS participants who contribute media to CS. Charles,=20 The use case section is at the end of this document https://datatracker.ietf.org/doc/draft-ram-siprec-metadata Please note the case where Focus is acting as SRC is simpler as all participants of conference which are connected to focus will in turn become participants of CS too. Thanks, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Thursday, January 27, 2011 1:09 PM > To: Charles Eckel (eckelcu); siprec@ietf.org > Subject: Re: [siprec] metadata model for participant that is not part > of CS >=20 > I am starting to see Charles's point. For a participant behind a > bridge, you don't really know what media he is contributing or what > media he is receiving. All you know for certain is that the bridge is a > participant. Perhaps we could assign multiple user identities to a > bridge participant, thereby reflecting users behind the bridge that may > or may not be contributing to the media the bridge sends and may or may > not be recipients of media the bridge receives. >=20 > Note that the model when the SRC is at the bridge, rather than outside > the bridge, is quite different. Also the model where the bridge is > switching, rather than mixing, might be different. >=20 > John (as individual) >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu) > > Sent: 26 January 2011 18:56 > > To: siprec@ietf.org > > Subject: [siprec] metadata model for participant that is not > > part of CS > > > > This is to follow up on some questions I raised regarding the > metadata > > model during the interim meeting Tuesday. > > My initial concern was that I thought we were allowing media > > streams to > > be defined without any participant. I now understand that is not the > > case; rather, a media stream is always associated with at least one > > participant, but that participant need not necessary be > > associated with > > the CS. > > Now I have some concern about participants that are not part > > of the CS. > > My concern is that the level of metadata we have for such > participants > > will be inconsistent at best. If the metadata for a non-CS > participant > > is incomplete, what do we plan to do? > > Also, I believe there was reference to a document that contains the > > model and some use cases. Which document is that? > > > > Thanks, > > Charles > > _______________________________________________ > > 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 From rmohanr@cisco.com Thu Jan 27 04:46:34 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2FA23A67A5 for ; Thu, 27 Jan 2011 04:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.174 X-Spam-Level: X-Spam-Status: No, score=-10.174 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpKxhI3uTG0D for ; Thu, 27 Jan 2011 04:46:32 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C720D3A67A3 for ; Thu, 27 Jan 2011 04:46:32 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEEAAP5QE1AaMHG/2dsb2JhbACWII5bc595mziFTwSFFYpc Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-5.cisco.com with ESMTP; 27 Jan 2011 12:49:35 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0RCn3QH014256; Thu, 27 Jan 2011 12:49:33 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Jan 2011 18:19:33 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Jan 2011 18:19:30 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD0512508B@XMB-BGL-417.cisco.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF7406989EA5@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] metadata model for participant that is not part of CS Thread-Index: Acu9iqr7ynF7z4Y5QUaRyQBZjCoEsQAFBbgQACAw7BA= References: <059AF07365DC474393A19A3AF187DF7406989EA5@NAHALD.us.int.genesyslab.com> From: "Ram Mohan R (rmohanr)" To: "Henry Lum" , "Charles Eckel (eckelcu)" , X-OriginalArrivalTime: 27 Jan 2011 12:49:33.0092 (UTC) FILETIME=[A540F640:01CBBE20] Subject: Re: [siprec] metadata model for participant that is not part of CS X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 12:46:34 -0000 Please see inline for comments: > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Henry Lum > Sent: Thursday, January 27, 2011 2:58 AM > To: Charles Eckel (eckelcu); siprec@ietf.org > Subject: Re: [siprec] metadata model for participant that is not part > of CS >=20 > Trying to come up with an instance diagram for what a conference mixer > looks like: >=20 > +-------------------------------+ > | Recording Session (RS) | > +-------------------------------+ > | > | > +-------------------------------+ > | Communication Session (CS) | > | Group(CSG) | > +-------------------------------+ > | Unique-id1 | > +-------------------------------+ > | > | > +----------------+ > | Communication | > | Session (CS)1 | > +----------------+ > | | > +----------------+ > | > |-------------------+ > | | > +---------------+ +---------------+ > | ParticipantA |--+--| ParticipantB | > +---------------+ | +---------------+ > | | | > sends receives sends > | | | > +---------------+ | +---------------+ > |Media Stream A | | |Media Stream B | > +---------------+ | +---------------+ > | > +---------------+ > |Media Stream C | > | (mixed stream)| > +---------------+ > | > sends > | > +---------------+ > | ParticipantC | > | (automated | > | announcement)| > +---------------+ >=20 >=20 > Media Stream C is the one that we are interested in and that is the > recorded stream in the RS. >=20 > It looks to me that we need some form of an automated participant that > produces the mixed media as well as acting as an automated participant > that produces any announcements to the conference mix. This way we can > tell who generated the announcements as well as the mix itself, > however, > I have a the same question as Charles where it is unclear to me whether > this automated participant should belong to any CS. >From your instance diagram, there are two participant A and B who are part of a CS and sending media streams A and B and they are receiving a media stream from another source [ C which could be MOH or mixed stream in this case]. As per the current model we could have Participants in media streams who are not participants in the CS. Now that depends on what we mean by participation in a CS. Our notion(used in the model) is: - A participant is part of CS if it is contributing in the signaling for the CS. So as per the current model Participant C is non-CS participant ( as it is not contributing to signaling) but contributing with only media to CS.=20 Thanks, Ram >=20 > Regards, > Henry >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Charles Eckel (eckelcu) > > Sent: Wednesday, January 26, 2011 1:56 PM > > To: siprec@ietf.org > > Subject: [siprec] metadata model for participant that is not part of > CS > > > > This is to follow up on some questions I raised regarding the > metadata > > model during the interim meeting Tuesday. > > My initial concern was that I thought we were allowing media streams > to > > be defined without any participant. I now understand that is not the > > case; rather, a media stream is always associated with at least one > > participant, but that participant need not necessary be associated > with > > the CS. > > Now I have some concern about participants that are not part of the > CS. > > My concern is that the level of metadata we have for such > participants > > will be inconsistent at best. If the metadata for a non-CS > participant > > is incomplete, what do we plan to do? > > Also, I believe there was reference to a document that contains the > > model and some use cases. Which document is that? > > > > Thanks, > > Charles > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec >=20 >=20 > ----------------------------------------------------------------------- > -------------------------------------------- > CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain > confidential and proprietary information of Alcatel-Lucent and/or its > affiliated entities. Access by the intended recipient only is > authorized. Any liability arising from any party acting, or refraining > from acting, on any information contained in this e-mail is hereby > excluded. If you are not the intended recipient, please notify the > sender immediately, destroy the original transmission and its > attachments and do not disclose the contents to any other person, use > it for any purpose, or store or copy the information in any medium. > Copyright in this e-mail and any attachments belongs to Alcatel-Lucent > and/or its affiliated entities. >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@cisco.com Thu Jan 27 04:57:02 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 043063A67E9 for ; Thu, 27 Jan 2011 04:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.513 X-Spam-Level: X-Spam-Status: No, score=-110.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eb4Irh0rFEih for ; Thu, 27 Jan 2011 04:56:58 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id F1DBC3A67E7 for ; Thu, 27 Jan 2011 04:56:57 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGb7QE1AZnwM/2dsb2JhbACke3Ofcps0hU8EhReHEINE Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 27 Jan 2011 13:00:00 +0000 Received: from [10.86.250.39] (bxb-vpn3-551.cisco.com [10.86.250.39]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0RCxxFn021865 for ; Thu, 27 Jan 2011 13:00:00 GMT Message-ID: <4D416C4F.3000804@cisco.com> Date: Thu, 27 Jan 2011 07:59:59 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: siprec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] metadata model for participant that is not part of CS X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 12:57:02 -0000 On 1/27/2011 2:39 AM, Elwell, John wrote: > I am starting to see Charles's point. For a participant behind a bridge, you don't really know what media he is contributing or what media he is receiving. All you know for certain is that the bridge is a participant. Perhaps we could assign multiple user identities to a bridge participant, thereby reflecting users behind the bridge that may or may not be contributing to the media the bridge sends and may or may not be recipients of media the bridge receives. > > Note that the model when the SRC is at the bridge, rather than outside the bridge, is quite different. Also the model where the bridge is switching, rather than mixing, might be different. I've been trying to ensure that there is enough flexibility in the model to describe all of these configurations. How the SRC *uses* that flexibility will be up to it. For instance, the SRC can choose to always include the UA that the media stream comes from as a sending participant, even if it is not contributing any of its own bits to the mix. The aspect of the model that has multiple senders to a single stream has the intrinsic limitation that you don't know, from the model, what parts of the stream were sent by which participant. You may be able to improve on that with data in the RTP/RTCP if the mixer does a good job. Perhaps there should be more info in the metadata to tie all that together. My knowledge of the details of RTP is scant, so somebody else will have to suggest something if they see a way to do that. Thanks, Paul > John (as individual) > >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu) >> Sent: 26 January 2011 18:56 >> To: siprec@ietf.org >> Subject: [siprec] metadata model for participant that is not >> part of CS >> >> This is to follow up on some questions I raised regarding the metadata >> model during the interim meeting Tuesday. >> My initial concern was that I thought we were allowing media >> streams to >> be defined without any participant. I now understand that is not the >> case; rather, a media stream is always associated with at least one >> participant, but that participant need not necessary be >> associated with >> the CS. >> Now I have some concern about participants that are not part >> of the CS. >> My concern is that the level of metadata we have for such participants >> will be inconsistent at best. If the metadata for a non-CS participant >> is incomplete, what do we plan to do? >> Also, I believe there was reference to a document that contains the >> model and some use cases. Which document is that? >> >> Thanks, >> Charles >> _______________________________________________ >> 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 > From acooper@cdt.org Thu Jan 27 04:59:37 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1D863A67F8 for ; Thu, 27 Jan 2011 04:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THahCYThM+AM for ; Thu, 27 Jan 2011 04:59:30 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id CB2273A67D4 for ; Thu, 27 Jan 2011 04:59:29 -0800 (PST) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Thu, 27 Jan 2011 08:02:21 -0500 Message-Id: From: Alissa Cooper To: "Elwell, John" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 27 Jan 2011 13:02:19 +0000 References: X-Mailer: Apple Mail (2.936) Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 12:59:38 -0000 As written, I think this use case (and the revised REQ-017) is still slightly ambiguous. There seem to be three cases: (1) Recording starts. Customer requests that recording be stopped. Recording stops. (2) Recording starts. Customer requests that recording be stopped and discarded. Recording stops. Recording is discarded. (3) Recording starts. Customer requests that recording be stopped and discarded. Recording stops but recording is not discarded. I think (1) is already covered between REQ-001 and REQ-011. I think (2) is by and large what we were discussing when we were talking about ditching REQ-015 and REQ-016. As noted during the virtual interim day 1, whether the SRS actually discards the recording depends on policy set by the SRC, which we had said was out of scope. BUT it sort of sounded like case (3) might be of interest -- i.e., that having the ability for an SRC to send an indication to the SRS of the customer's preference that the recording be discarded, even if that preference will not always be honored, is something that we may want to support. If that's the case, it might merit its own requirement ("The mechanism MUST provide a means for an SRC to indicate to an SRS a preference to discard a recording" or something like that). Alissa On Jan 27, 2011, at 7:03 AM, Elwell, John wrote: > Just changed the subject line so that people concerned will notice it. > > John > >> -----Original Message----- >> From: Dave Smith [mailto:Dave.d.Smith@alcatel-lucent.com] >> Sent: 26 January 2011 21:22 >> To: Elwell, John; siprec@ietf.org >> Subject: RE: [siprec] Minutes day 1 >> >> Hi, >> Here is my input to my Action Item related to REQ-015/016 - >> to raise on >> the list any fresh requirements concerning what CS >> participants might be >> able to request regarding "canceling" and/or "discarding" recording. >> >> It seems that REQ-017 already covers the basic idea; however, >> REQ-017 is >> only valid " prior to the start of recording ". My concern >> was for the >> mechanism to also work "during" recording. >> Therefore, my proposal is to consider to update REQ-017 as follows: >> >> Currently it reads: >> o REQ-017 The mechanism MUST support a means for an authorized >> participant involved in a CS to request, prior to the start of >> recording, that the CS not be recorded >> >> Change to: >> o REQ-017 The mechanism MUST support a means for an authorized >> participant involved in a CS to request, during or prior >> to the start >> of >> recording, that the CS not be recorded >> >> >> Use Case supporting this change: >> 1. Customer calls a contact center >> 2. Agent answers the phone >> 3. Customer starts discussing their issue with the Agent >> 4. Customer realizes that the call is being recorded (e.g., >> they hear a "beep" tone indicating that the call is currently being >> recorded) >> 5. Customer decides that they do not want the call to be >> recorded >> 6. Customer requests that the call not be recorded (e.g., >> customer phone application is used to send a signal within the CS >> that >> can be received/interpreted by the SRC) >> 7. The SRC stops the recording >> Also note the following that could further be done, if an >> implementation >> desires (no req'ts needed): >> Optional: 8. The SRC sends metadata to the SRS indicating that >> the Customer requested that the call NOT be recorded >> Optional: 9. The SRS uses its internal policy procedures and >> decides to delete the recorded audio file from the Customer recording >> >> >> >> Let me know your inputs and if this change makes sense. >> >> >> Regards, >> Dave >> >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf >> Of Elwell, John >> Sent: Tuesday, January 25, 2011 2:24 PM >> To: siprec@ietf.org >> Subject: [siprec] Minutes day 1 >> >> Minutes of the SIPREC WG Interim Virtual Meeting >> 2011-01-25, 15.00-17.00 GMT/UTC and >> 2011-01-25, 14.00-16.00 GMT/UTC >> =============================================== >> Meeting chaired by Brian Rosen and John Elwell. >> >> Participants (session 1): Brian Rosen, John Elwell, Ken Rehor, Leon >> Portman, Henry Lum, Ram >> Mohen, Andy Hutton, Alan Johnston, Gonzalo Camarillo, Paul >> Kyzivat, Dave >> Smith, Parthasarathi, Dan Romascanu, Alissa Cooper, Charles Eckel >> >> Minutes produced by John Elwell. >> >> Webex chat: See end of these minutes. Jabber was not used. >> >> Recording day 1: >> https://workgreen.webex.com/workgreen/ldr.php?AT=pb&SP=MC&rID= >> 8263017&rK >> ey=19329980a044b45b >> >> Meeting started at 15.02. >> >> Topic - Administrivia (chairs) >> ============================== >> Slides: http://kenrehor.com/ietf/siprec/IETF79.2/Chairs.pdf >> >> No changes to published agenda. >> >> >> Topic - Requirements (Ken Rehor) >> draft-ietf-siprec-req-06 >> ================================ >> Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-req/ >> Slides: >> http://kenrehor.com/ietf/siprec/IETF79.2/IETF-79.2-SIPREC-Req- > 2011-01-25 >> .pdf >> >> Slide 4 - proposal to delete REQ-015/016. It was noted that these >> requirements talk about "cancel and discard". After some discussion, >> there seemed to be agreement that the "cancel" part was >> covered by other >> requirements (e.g., you can pause and not resume, effectively >> cancelling). So the main issue concerned the "discard" part. It was >> noted that previous agreements relating to privacy had reached the >> conclusion that the retention of recordings is an issue for >> the SRS, and >> outside the scope of SIPREC. There was no objection to >> deleting the two >> requirements. >> >> Although the main focus of the requirements is on what happens on the >> SRC-SRS interface, Dave Smith brought up the question of whether a >> participant, whose SIP UA might not be collocated with the SRC, can >> request the pausing / stopping of a recording, or even >> request deletion >> of the recording. This would be a requirement impacting the CS, as >> opposed to the RS, and it was noted that none of the solution work >> has >> touched on that (although the earlier draft from Alan >> Johnston did have >> provision for an indication on the CS signalling path that >> recording is >> taking place, but this was not brought forward into the >> present protocol >> draft). Dave was invited to raise on the list any fresh requirements >> concerning what CS participants might be able to request. >> >> Slide 5 - proposed new requirement on multiple media streams for the >> same media type. It was observed that REQ-010 was probably intended >> to >> cover this case, and Ken will propose words to enhance REQ-010 to >> make >> it clearer. >> >> Slide 6 - removal of REQ-021. There was no objection to removal. >> >> Ken will try to seek resolution of the issues above and then publish >> -07, which should be very close to being ready to submit to the IESG. >> >> >> Topic - Metadata model (Ram Mohan) >> draft-ram-siprec-metadata-03 >> ================================================ >> Draft: https://datatracker.ietf.org/doc/draft-ram-siprec-metadata/ >> Slides: ???? >> >> Slide 4: Ram explained why an association between Media Stream and CS >> had been introduced, because of the injection of things like music on >> hold, leading to a media stream without participant. Charles wondered >> why music on hold could not be considered a participant. Ram and Paul >> explained there were also conference cases where a participant might >> host a conference on his device, but those behind the conferencing >> device might not be considered CS participants. Charles asked why the >> conference focus could not be considered a participant. Paul >> explained >> that the SRC could obtain, using the conference event >> package, a list of >> participants from the focus, and those participants would >> contribute to >> the media stream, but those participants would not be part of the >> CS - >> that would be the role of the focus. Henry thought a mixer might be >> considered a participant, but Paul explained that if you can obtain a >> roster of people behind the mixer, those might be considered >> participants rathe >> r than the mixer. So there can be participants in the media that are >> not participants in the CS. Charles was worried that some >> media streams >> might not have any identified participants who are generating the >> stream. Paul explained that, assuming the media from the participants >> are mixed, you would see one media stream and a list of participants. >> One participant might be joined to the CS and the others would not >> be. >> Paul thinks we need to explore some use cases and see how >> they would be >> represented using this model. So if people have particular use cases, >> make them known and we check how they would be represented. Ram will >> solicit use cases. Partha also had concerns similar to those >> of Charles, >> but Charles was beginning to see how the present model might >> work if you >> can get information about non-CS participants who are >> generating a media >> stream. Paul pointed out that the model does cater for a participant >> that is not part of a CS. Charles was invited to post his >> continued conc >> erns / scenarios to the list, but Paul thinks the use cases concerned >> are already covered by the model. >> >> Slide 6 (CS Group): Nobody on list had come up with a reason >> for having >> more than one CSG associated with a single CS, and the conclusion >> reached on the list seems to stand. >> >> Slide 7 (CS): No comments on CS slide, except that forced >> deletion is to >> be removed in line with the requirements discussion. >> >> Slide 8 (Participant): Clarified that the multiple AORs are >> aliases, in >> the sense of P-Asserted-Identity being able to carry aliases. >> >> Concerning the issue of whether participant role is needed as an >> attribute, Leon suggested it could be done in application data, but >> asked whether we would then publish some application data dictionary. >> Paul suggested that application data is just some additional >> XML in some >> other namespace, so some other group could get together and define >> it. >> Leon was concerned that without some sort of standardization, >> different >> vendors would implement it differently. John suggested we >> need to decide >> what things are needed by 80% of deployments and standardize those in >> this group, so if that is the case for participant role, we should >> standardize it. Partha wanted to include participant role, even >> though >> there might be some cases where it is not available. Paul pointed out >> that we had had considerable list discussion on the difficulties of >> figuring out the role: UAC/UAS is transaction specific, >> inbound/outbound >> is problematic, and incoming/outgoing, whilst it might work in some >> cases, it w >> ill not always work. Perhaps those focused on call centres >> can say what >> might/might not work. In conclusion, this has to be taken back to the >> list. Without repeating the old arguments, those wanting to include >> participant role should indicate what are the likely mechanisms that >> might support it. >> >> Slide 10 (Media Stream): How to model media streams that are not >> recorded (rejected by SRS or no capability at SRS). Dave thought was >> important that you have some information in the metadata that >> there was >> media that was available for recording but couldn't be recorded, but >> there are two cases: where you don't want to record, or where >> because of >> a temporary limitation you are unable to record but might >> want to record >> later. Paul agreed, but was concerned about the details, although >> that >> is very much down to the mechanism, e.g., does the SRC need to keep >> offering the stream? >> >> Partha asked a question on start time and end time. Ram clarified >> this >> is these are start and end times of the CS media. It was pointed out >> that we have wall clock time in the metadata, and other times can be >> relative. Leon suggested there may be a need to retransmit wall clock >> time occasionally, to compensate for drift. >> >> Henry asked whether media stream reference should be part of the >> mechanism rather than an attribute. >> >> Slide 10 (Application data): Leon agreed with the extensible >> approach, >> based on different namespaces. Paul said that he would be tempted to >> stop calling it application data and call it extension data. >> John (from >> the floor) questioned whether it really is an object, or just >> attributes >> of other objects. Paul said it was just an artefact of how >> the model is >> drawn, but in the solution it would just be extensibility data. The >> authors will rework this with these comments in mind. >> >> On next steps, people are asked to review and submit further >> comments on >> -03, and -04 will be produced in due course, after which we might be >> consider adoption as a WG item. In particular, we need closure on the >> long discussion of media stream relationships. >> >> >> Topic - Protocol (Henry Lum / Leon Portman) >> draft-portman-siprec-protocol-02 >> ================================================ >> Draft: https://datatracker.ietf.org/doc/draft-portman-siprec- >> protocol/ >> Slides: http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol >> %20- >> %20virtual%20interim%20Dec%2016%202010.pdf >> >> Slide 4 (Persistent recording): Leon pointed out that the >> whole idea of >> persistent recording is not to spend time negotiating m-lines >> when a CS >> starts - so he prefers the second option on the slide. For SRCs that >> support a large number of parallel CSs, the SRC could pre-negotiate a >> large number of m-lines (perhaps based on licensing), rather like >> provisioning trunks. Paul felt that the other option should >> be kept open >> - a slight delay in negotiating a new m-line could be handled by >> transmitting the data slightly delayed, without losing any. Henry >> also >> mentioned the possibility of the offer-answer failing. It was >> questioned >> whether there needs to be something in the protocol to indicate the >> delay. This issue should be brought to the list. >> >> >> Day 1 wrap-up >> ================================ >> >> It was agreed that on the second day we will start by completing the >> Protocol topic and then do the metadata format topic. >> >> The meeting was closed at 17.00. >> >> >> Day 1 chat log >> =============================== >> January 25, 2011 3:19:58 PM from Alissa Cooper >> to Everyone: I'm not in a place where I can speak in the audio, but I >> think we decided not to have requirements related to what >> happens to the >> recording after it has been made. >> >> January 25, 2011 3:30:32 PM from Alissa Cooper >> to Everyone: it seems like there are cases where the hints are >> valuable even if they aren't always honoured >> >> January 25, 2011 3:39:51 PM from Alissa Cooper >> to Everyone: it's old, I'll take it to the list >> >> January 25, 2011 4:59:32 PM from Kenneth Rehor >> to Everyone: Unfortunately I have to drop off now. TTY tomorrow. >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> >> >> -------------------------------------------------------------- >> ----------------------------------------------------- >> CONFIDENTIALITY NOTICE: This e-mail and any files attached >> may contain confidential and proprietary information of >> Alcatel-Lucent and/or its affiliated entities. Access by the >> intended recipient only is authorized. Any liability arising >> from any party acting, or refraining from acting, on any >> information contained in this e-mail is hereby excluded. If >> you are not the intended recipient, please notify the sender >> immediately, destroy the original transmission and its >> attachments and do not disclose the contents to any other >> person, use it for any purpose, or store or copy the >> information in any medium. Copyright in this e-mail and any >> attachments belongs to Alcatel-Lucent and/or its affiliated entities. >> >> > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From pkyzivat@cisco.com Thu Jan 27 05:27:13 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE8643A65A6 for ; Thu, 27 Jan 2011 05:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.517 X-Spam-Level: X-Spam-Status: No, score=-110.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyHfR9tqHv3e for ; Thu, 27 Jan 2011 05:27:11 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 407803A6452 for ; Thu, 27 Jan 2011 05:27:11 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEEAGICQU1AZnwM/2dsb2JhbACWII5bc4grl1ybOAKCdoJXBIUXhxCDRA Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 27 Jan 2011 13:30:14 +0000 Received: from [10.86.250.39] (bxb-vpn3-551.cisco.com [10.86.250.39]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0RDUDND001250 for ; Thu, 27 Jan 2011 13:30:13 GMT Message-ID: <4D417365.60205@cisco.com> Date: Thu, 27 Jan 2011 08:30:13 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: siprec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 13:27:14 -0000 Inline On 1/27/2011 8:02 AM, Alissa Cooper wrote: > As written, I think this use case (and the revised REQ-017) is still > slightly ambiguous. There seem to be three cases: > > (1) Recording starts. Customer requests that recording be stopped. > Recording stops. > (2) Recording starts. Customer requests that recording be stopped and > discarded. Recording stops. Recording is discarded. > (3) Recording starts. Customer requests that recording be stopped and > discarded. Recording stops but recording is not discarded. > > I think (1) is already covered between REQ-001 and REQ-011. > > I think (2) is by and large what we were discussing when we were talking > about ditching REQ-015 and REQ-016. As noted during the virtual interim > day 1, whether the SRS actually discards the recording depends on policy > set by the SRC, which we had said was out of scope. > > BUT it sort of sounded like case (3) might be of interest -- i.e., that > having the ability for an SRC to send an indication to the SRS of the > customer's preference that the recording be discarded, even if that > preference will not always be honored, is something that we may want to > support. If that's the case, it might merit its own requirement ("The > mechanism MUST provide a means for an SRC to indicate to an SRS a > preference to discard a recording" or something like that). There is a fundamental difference between 1 and 2/3. The customer (I assume this to be a participant not in control of the SRC) can *ask* that the recording be discarded. But he can not be certain that is has been. Similarly, the agent (or any participant that *is* in control of the SRC) could (if we provide a suitable mechanism) *ask* the SRS to discard the recording. But again he cannot be certain it has been. We could even provide a mechanism to ACK/NACK a request to discard a recording. That could allow the SRC a bit more knowledge, but the SRS could still by lying. Only the SRS *knows* if the recording has been discarded. Whether it does so when asked will depend upon its operating policies, which could include policies that violate the law. So, given all of that, is it worth the trouble to include a mechanism to request the discard of a recording, and to ACK/NACK that request??? If that is felt to be important, then it will be a bit of work, because we will need to define *what* is to be discarded, and that is non-trivial. I mentioned on the list the mechanism that exists in some email systems to "retract" an email. AFAIK this very rarely "works" - it often results in all the recipients getting another email saying "John Smith would like to recall email xyz", but *does not* result in the intended result. I think requesting that a recording be discarded falls into he same category. If you seriously want to ensure that a recording has been discarded, then I suggest you hire a lawyer and file a lawsuit. Thanks, Paul > Alissa > > On Jan 27, 2011, at 7:03 AM, Elwell, John wrote: > >> Just changed the subject line so that people concerned will notice it. >> >> John >> >>> -----Original Message----- >>> From: Dave Smith [mailto:Dave.d.Smith@alcatel-lucent.com] >>> Sent: 26 January 2011 21:22 >>> To: Elwell, John; siprec@ietf.org >>> Subject: RE: [siprec] Minutes day 1 >>> >>> Hi, >>> Here is my input to my Action Item related to REQ-015/016 - >>> to raise on >>> the list any fresh requirements concerning what CS >>> participants might be >>> able to request regarding "canceling" and/or "discarding" recording. >>> >>> It seems that REQ-017 already covers the basic idea; however, >>> REQ-017 is >>> only valid " prior to the start of recording ". My concern >>> was for the >>> mechanism to also work "during" recording. >>> Therefore, my proposal is to consider to update REQ-017 as follows: >>> >>> Currently it reads: >>> o REQ-017 The mechanism MUST support a means for an authorized >>> participant involved in a CS to request, prior to the start of >>> recording, that the CS not be recorded >>> >>> Change to: >>> o REQ-017 The mechanism MUST support a means for an authorized >>> participant involved in a CS to request, during or prior >>> to the start >>> of >>> recording, that the CS not be recorded >>> >>> >>> Use Case supporting this change: >>> 1. Customer calls a contact center >>> 2. Agent answers the phone >>> 3. Customer starts discussing their issue with the Agent >>> 4. Customer realizes that the call is being recorded (e.g., >>> they hear a "beep" tone indicating that the call is currently being >>> recorded) >>> 5. Customer decides that they do not want the call to be >>> recorded >>> 6. Customer requests that the call not be recorded (e.g., >>> customer phone application is used to send a signal within the CS that >>> can be received/interpreted by the SRC) >>> 7. The SRC stops the recording >>> Also note the following that could further be done, if an >>> implementation >>> desires (no req'ts needed): >>> Optional: 8. The SRC sends metadata to the SRS indicating that >>> the Customer requested that the call NOT be recorded >>> Optional: 9. The SRS uses its internal policy procedures and >>> decides to delete the recorded audio file from the Customer recording >>> >>> >>> >>> Let me know your inputs and if this change makes sense. >>> >>> >>> Regards, >>> Dave >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org] On Behalf >>> Of Elwell, John >>> Sent: Tuesday, January 25, 2011 2:24 PM >>> To: siprec@ietf.org >>> Subject: [siprec] Minutes day 1 >>> >>> Minutes of the SIPREC WG Interim Virtual Meeting >>> 2011-01-25, 15.00-17.00 GMT/UTC and >>> 2011-01-25, 14.00-16.00 GMT/UTC >>> =============================================== >>> Meeting chaired by Brian Rosen and John Elwell. >>> >>> Participants (session 1): Brian Rosen, John Elwell, Ken Rehor, Leon >>> Portman, Henry Lum, Ram >>> Mohen, Andy Hutton, Alan Johnston, Gonzalo Camarillo, Paul >>> Kyzivat, Dave >>> Smith, Parthasarathi, Dan Romascanu, Alissa Cooper, Charles Eckel >>> >>> Minutes produced by John Elwell. >>> >>> Webex chat: See end of these minutes. Jabber was not used. >>> >>> Recording day 1: >>> https://workgreen.webex.com/workgreen/ldr.php?AT=pb&SP=MC&rID= >>> 8263017&rK >>> ey=19329980a044b45b >>> >>> Meeting started at 15.02. >>> >>> Topic - Administrivia (chairs) >>> ============================== >>> Slides: http://kenrehor.com/ietf/siprec/IETF79.2/Chairs.pdf >>> >>> No changes to published agenda. >>> >>> >>> Topic - Requirements (Ken Rehor) >>> draft-ietf-siprec-req-06 >>> ================================ >>> Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-req/ >>> Slides: >>> http://kenrehor.com/ietf/siprec/IETF79.2/IETF-79.2-SIPREC-Req- >> 2011-01-25 >>> .pdf >>> >>> Slide 4 - proposal to delete REQ-015/016. It was noted that these >>> requirements talk about "cancel and discard". After some discussion, >>> there seemed to be agreement that the "cancel" part was >>> covered by other >>> requirements (e.g., you can pause and not resume, effectively >>> cancelling). So the main issue concerned the "discard" part. It was >>> noted that previous agreements relating to privacy had reached the >>> conclusion that the retention of recordings is an issue for >>> the SRS, and >>> outside the scope of SIPREC. There was no objection to >>> deleting the two >>> requirements. >>> >>> Although the main focus of the requirements is on what happens on the >>> SRC-SRS interface, Dave Smith brought up the question of whether a >>> participant, whose SIP UA might not be collocated with the SRC, can >>> request the pausing / stopping of a recording, or even >>> request deletion >>> of the recording. This would be a requirement impacting the CS, as >>> opposed to the RS, and it was noted that none of the solution work has >>> touched on that (although the earlier draft from Alan >>> Johnston did have >>> provision for an indication on the CS signalling path that >>> recording is >>> taking place, but this was not brought forward into the >>> present protocol >>> draft). Dave was invited to raise on the list any fresh requirements >>> concerning what CS participants might be able to request. >>> >>> Slide 5 - proposed new requirement on multiple media streams for the >>> same media type. It was observed that REQ-010 was probably intended to >>> cover this case, and Ken will propose words to enhance REQ-010 to make >>> it clearer. >>> >>> Slide 6 - removal of REQ-021. There was no objection to removal. >>> >>> Ken will try to seek resolution of the issues above and then publish >>> -07, which should be very close to being ready to submit to the IESG. >>> >>> >>> Topic - Metadata model (Ram Mohan) >>> draft-ram-siprec-metadata-03 >>> ================================================ >>> Draft: https://datatracker.ietf.org/doc/draft-ram-siprec-metadata/ >>> Slides: ???? >>> >>> Slide 4: Ram explained why an association between Media Stream and CS >>> had been introduced, because of the injection of things like music on >>> hold, leading to a media stream without participant. Charles wondered >>> why music on hold could not be considered a participant. Ram and Paul >>> explained there were also conference cases where a participant might >>> host a conference on his device, but those behind the conferencing >>> device might not be considered CS participants. Charles asked why the >>> conference focus could not be considered a participant. Paul explained >>> that the SRC could obtain, using the conference event >>> package, a list of >>> participants from the focus, and those participants would >>> contribute to >>> the media stream, but those participants would not be part of the CS - >>> that would be the role of the focus. Henry thought a mixer might be >>> considered a participant, but Paul explained that if you can obtain a >>> roster of people behind the mixer, those might be considered >>> participants rathe >>> r than the mixer. So there can be participants in the media that are >>> not participants in the CS. Charles was worried that some >>> media streams >>> might not have any identified participants who are generating the >>> stream. Paul explained that, assuming the media from the participants >>> are mixed, you would see one media stream and a list of participants. >>> One participant might be joined to the CS and the others would not be. >>> Paul thinks we need to explore some use cases and see how >>> they would be >>> represented using this model. So if people have particular use cases, >>> make them known and we check how they would be represented. Ram will >>> solicit use cases. Partha also had concerns similar to those >>> of Charles, >>> but Charles was beginning to see how the present model might >>> work if you >>> can get information about non-CS participants who are >>> generating a media >>> stream. Paul pointed out that the model does cater for a participant >>> that is not part of a CS. Charles was invited to post his >>> continued conc >>> erns / scenarios to the list, but Paul thinks the use cases concerned >>> are already covered by the model. >>> >>> Slide 6 (CS Group): Nobody on list had come up with a reason >>> for having >>> more than one CSG associated with a single CS, and the conclusion >>> reached on the list seems to stand. >>> >>> Slide 7 (CS): No comments on CS slide, except that forced >>> deletion is to >>> be removed in line with the requirements discussion. >>> >>> Slide 8 (Participant): Clarified that the multiple AORs are >>> aliases, in >>> the sense of P-Asserted-Identity being able to carry aliases. >>> >>> Concerning the issue of whether participant role is needed as an >>> attribute, Leon suggested it could be done in application data, but >>> asked whether we would then publish some application data dictionary. >>> Paul suggested that application data is just some additional >>> XML in some >>> other namespace, so some other group could get together and define it. >>> Leon was concerned that without some sort of standardization, >>> different >>> vendors would implement it differently. John suggested we >>> need to decide >>> what things are needed by 80% of deployments and standardize those in >>> this group, so if that is the case for participant role, we should >>> standardize it. Partha wanted to include participant role, even though >>> there might be some cases where it is not available. Paul pointed out >>> that we had had considerable list discussion on the difficulties of >>> figuring out the role: UAC/UAS is transaction specific, >>> inbound/outbound >>> is problematic, and incoming/outgoing, whilst it might work in some >>> cases, it w >>> ill not always work. Perhaps those focused on call centres >>> can say what >>> might/might not work. In conclusion, this has to be taken back to the >>> list. Without repeating the old arguments, those wanting to include >>> participant role should indicate what are the likely mechanisms that >>> might support it. >>> >>> Slide 10 (Media Stream): How to model media streams that are not >>> recorded (rejected by SRS or no capability at SRS). Dave thought was >>> important that you have some information in the metadata that >>> there was >>> media that was available for recording but couldn't be recorded, but >>> there are two cases: where you don't want to record, or where >>> because of >>> a temporary limitation you are unable to record but might >>> want to record >>> later. Paul agreed, but was concerned about the details, although that >>> is very much down to the mechanism, e.g., does the SRC need to keep >>> offering the stream? >>> >>> Partha asked a question on start time and end time. Ram clarified this >>> is these are start and end times of the CS media. It was pointed out >>> that we have wall clock time in the metadata, and other times can be >>> relative. Leon suggested there may be a need to retransmit wall clock >>> time occasionally, to compensate for drift. >>> >>> Henry asked whether media stream reference should be part of the >>> mechanism rather than an attribute. >>> >>> Slide 10 (Application data): Leon agreed with the extensible approach, >>> based on different namespaces. Paul said that he would be tempted to >>> stop calling it application data and call it extension data. >>> John (from >>> the floor) questioned whether it really is an object, or just >>> attributes >>> of other objects. Paul said it was just an artefact of how >>> the model is >>> drawn, but in the solution it would just be extensibility data. The >>> authors will rework this with these comments in mind. >>> >>> On next steps, people are asked to review and submit further >>> comments on >>> -03, and -04 will be produced in due course, after which we might be >>> consider adoption as a WG item. In particular, we need closure on the >>> long discussion of media stream relationships. >>> >>> >>> Topic - Protocol (Henry Lum / Leon Portman) >>> draft-portman-siprec-protocol-02 >>> ================================================ >>> Draft: https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ >>> Slides: http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20- >>> %20virtual%20interim%20Dec%2016%202010.pdf >>> >>> Slide 4 (Persistent recording): Leon pointed out that the >>> whole idea of >>> persistent recording is not to spend time negotiating m-lines >>> when a CS >>> starts - so he prefers the second option on the slide. For SRCs that >>> support a large number of parallel CSs, the SRC could pre-negotiate a >>> large number of m-lines (perhaps based on licensing), rather like >>> provisioning trunks. Paul felt that the other option should >>> be kept open >>> - a slight delay in negotiating a new m-line could be handled by >>> transmitting the data slightly delayed, without losing any. Henry also >>> mentioned the possibility of the offer-answer failing. It was >>> questioned >>> whether there needs to be something in the protocol to indicate the >>> delay. This issue should be brought to the list. >>> >>> >>> Day 1 wrap-up >>> ================================ >>> >>> It was agreed that on the second day we will start by completing the >>> Protocol topic and then do the metadata format topic. >>> >>> The meeting was closed at 17.00. >>> >>> >>> Day 1 chat log >>> =============================== >>> January 25, 2011 3:19:58 PM from Alissa Cooper >>> to Everyone: I'm not in a place where I can speak in the audio, but I >>> think we decided not to have requirements related to what >>> happens to the >>> recording after it has been made. >>> >>> January 25, 2011 3:30:32 PM from Alissa Cooper >>> to Everyone: it seems like there are cases where the hints are >>> valuable even if they aren't always honoured >>> >>> January 25, 2011 3:39:51 PM from Alissa Cooper >>> to Everyone: it's old, I'll take it to the list >>> >>> January 25, 2011 4:59:32 PM from Kenneth Rehor >>> to Everyone: Unfortunately I have to drop off now. TTY tomorrow. >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >>> >>> -------------------------------------------------------------- >>> ----------------------------------------------------- >>> CONFIDENTIALITY NOTICE: This e-mail and any files attached >>> may contain confidential and proprietary information of >>> Alcatel-Lucent and/or its affiliated entities. Access by the >>> intended recipient only is authorized. Any liability arising >>> from any party acting, or refraining from acting, on any >>> information contained in this e-mail is hereby excluded. If >>> you are not the intended recipient, please notify the sender >>> immediately, destroy the original transmission and its >>> attachments and do not disclose the contents to any other >>> person, use it for any purpose, or store or copy the >>> information in any medium. Copyright in this e-mail and any >>> attachments belongs to Alcatel-Lucent and/or its affiliated entities. >>> >>> >> _______________________________________________ >> 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 > From pkyzivat@cisco.com Thu Jan 27 05:44:53 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DD413A6838 for ; Thu, 27 Jan 2011 05:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.521 X-Spam-Level: X-Spam-Status: No, score=-110.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lLmc9dl4TaT for ; Thu, 27 Jan 2011 05:44:52 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id CDFF43A6803 for ; Thu, 27 Jan 2011 05:44:51 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEEAOcFQU1AZnwM/2dsb2JhbACWII5bc599mzmFTwSFF4cQg0Q Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 27 Jan 2011 13:47:55 +0000 Received: from [10.86.250.39] (bxb-vpn3-551.cisco.com [10.86.250.39]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0RDlsjx006785 for ; Thu, 27 Jan 2011 13:47:54 GMT Message-ID: <4D41778A.1050809@cisco.com> Date: Thu, 27 Jan 2011 08:47:54 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: siprec@ietf.org References: <059AF07365DC474393A19A3AF187DF7406989EA5@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF7406989EA5@NAHALD.us.int.genesyslab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] metadata model for participant that is not part of CS X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 13:44:53 -0000 I think I already commented on this, but in case... (I presume you omitted the receivers of streams A and B because it isn't interesting.) What you describe is certainly one way that this scenario could be reported by the SRC. It is equally possible for the SRC to report the UA that provides the automated announcement as another CS participant. And there are multiple ways that might be accomplished: - it could be another participant in CS1. (But if there is no sip signaling, then that seems problematic.) - there could be another CS2 in same CSG with CS1, having the media player as a participant. (But then its not clear who the other participant in CS2 would be.) - we could expand the definition of participation in a CS to encompass signaling other than sip signaling. I'm open to that, but I think defining that might be difficult. - or we could leave it as you have shown it. From a model perspective participant C provided MS C "by magic". Its that way because it is by means that we have not standardized. But the participant info still has the potential to have all the same info as a CS participant. (Exactly what is there depends on what info the SRC has available to it.) "Extra" information about participant C can also be provided as AppData. Thanks, Paul On 1/26/2011 4:27 PM, Henry Lum wrote: > Trying to come up with an instance diagram for what a conference mixer > looks like: > > +-------------------------------+ > | Recording Session (RS) | > +-------------------------------+ > | > | > +-------------------------------+ > | Communication Session (CS) | > | Group(CSG) | > +-------------------------------+ > | Unique-id1 | > +-------------------------------+ > | > | > +----------------+ > | Communication | > | Session (CS)1 | > +----------------+ > | | > +----------------+ > | > |-------------------+ > | | > +---------------+ +---------------+ > | ParticipantA |--+--| ParticipantB | > +---------------+ | +---------------+ > | | | > sends receives sends > | | | > +---------------+ | +---------------+ > |Media Stream A | | |Media Stream B | > +---------------+ | +---------------+ > | > +---------------+ > |Media Stream C | > | (mixed stream)| > +---------------+ > | > sends > | > +---------------+ > | ParticipantC | > | (automated | > | announcement)| > +---------------+ > > > Media Stream C is the one that we are interested in and that is the > recorded stream in the RS. > > It looks to me that we need some form of an automated participant that > produces the mixed media as well as acting as an automated participant > that produces any announcements to the conference mix. This way we can > tell who generated the announcements as well as the mix itself, however, > I have a the same question as Charles where it is unclear to me whether > this automated participant should belong to any CS. > > Regards, > Henry > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Charles Eckel (eckelcu) >> Sent: Wednesday, January 26, 2011 1:56 PM >> To: siprec@ietf.org >> Subject: [siprec] metadata model for participant that is not part of > CS >> >> This is to follow up on some questions I raised regarding the metadata >> model during the interim meeting Tuesday. >> My initial concern was that I thought we were allowing media streams > to >> be defined without any participant. I now understand that is not the >> case; rather, a media stream is always associated with at least one >> participant, but that participant need not necessary be associated > with >> the CS. >> Now I have some concern about participants that are not part of the > CS. >> My concern is that the level of metadata we have for such participants >> will be inconsistent at best. If the metadata for a non-CS participant >> is incomplete, what do we plan to do? >> Also, I believe there was reference to a document that contains the >> model and some use cases. Which document is that? >> >> Thanks, >> Charles >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > > > ------------------------------------------------------------------------------------------------------------------- > CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities. > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From pkyzivat@cisco.com Thu Jan 27 06:01:14 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A5963A683E for ; Thu, 27 Jan 2011 06:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcBuZotrStRF for ; Thu, 27 Jan 2011 06:01:13 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 4C1793A683B for ; Thu, 27 Jan 2011 06:01:13 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao4FAJYKQU1AZnwM/2dsb2JhbACWX44cc6AAmzuFTwSFF4cQg0Q Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 27 Jan 2011 14:04:16 +0000 Received: from [10.86.250.39] (bxb-vpn3-551.cisco.com [10.86.250.39]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0RE4GpX013427 for ; Thu, 27 Jan 2011 14:04:16 GMT Message-ID: <4D417B60.7020506@cisco.com> Date: Thu, 27 Jan 2011 09:04:16 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: siprec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] metadata model for participant that is not part of CS X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 14:01:14 -0000 On 1/26/2011 1:55 PM, Charles Eckel (eckelcu) wrote: > This is to follow up on some questions I raised regarding the metadata > model during the interim meeting Tuesday. > My initial concern was that I thought we were allowing media streams to > be defined without any participant. I now understand that is not the > case; rather, a media stream is always associated with at least one > participant, but that participant need not necessary be associated with > the CS. > Now I have some concern about participants that are not part of the CS. > My concern is that the level of metadata we have for such participants > will be inconsistent at best. If the metadata for a non-CS participant > is incomplete, what do we plan to do? > Also, I believe there was reference to a document that contains the > model and some use cases. Which document is that? The bottom line is that we will have to live with metadata describing what the SRC knows about the situation. What it doesn't know it can't report. Beyond that, there may be things the SRC knows that can't be represented with the metamodel format we adopt. So, if there is something that you think the SRC might know, that we can define in a standard, that is not currently in the model, then speak up. So far the only thing I suspect is if the SRC knows of a non-sip signaling relationship to some media participant. But unless we can get more specific that "non-sip signaling" its going to be hard to encode it. I do think we may need to broaden the optional attributes of a Participant. Using a sip URI works for those in a signaling relationship, but for those that are not this may not work. The "name" has a lot of latitude, but doesn't lend itself to automated processing. E.g. we may need ability to include IDs from RTP. Of course this can also be covered by AppData until we get it right. Thanks, Paul From Henry.Lum@alcatel-lucent.com Thu Jan 27 06:51:16 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E4383A68CF for ; Thu, 27 Jan 2011 06:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKeHXQMng1id for ; Thu, 27 Jan 2011 06:51:15 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id E2F2C3A68CC for ; Thu, 27 Jan 2011 06:51:14 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p0REsGFg009149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Jan 2011 08:54:16 -0600 (CST) Received: from relay-out2.dc (relay-out2.dc.genesyslab.com [172.22.68.188]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0REsEI8005840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Jan 2011 08:54:16 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc (8.13.8+Sun/8.13.8) with ESMTP id p0REsDVZ000136; Thu, 27 Jan 2011 06:54:14 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Jan 2011 06:54:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Jan 2011 06:54:12 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF7406989F52@NAHALD.us.int.genesyslab.com> In-Reply-To: <4D41778A.1050809@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] metadata model for participant that is not part of CS Thread-Index: Acu+KNHIz/+MD4lpS/mC0uZxUdBSPgABsEuw References: <059AF07365DC474393A19A3AF187DF7406989EA5@NAHALD.us.int.genesyslab.com> <4D41778A.1050809@cisco.com> From: "Henry Lum" To: "Paul Kyzivat" , X-OriginalArrivalTime: 27 Jan 2011 14:54:13.0659 (UTC) FILETIME=[1004E6B0:01CBBE32] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [siprec] metadata model for participant that is not part of CS X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 14:51:16 -0000 Inline. > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Thursday, January 27, 2011 8:48 AM > To: siprec@ietf.org > Subject: Re: [siprec] metadata model for participant that is not part > of CS >=20 > I think I already commented on this, but in case... >=20 > (I presume you omitted the receivers of streams A and B because it > isn't > interesting.) >=20 [[hlum]] Right, the automated participant should have a line to receive media stream A and media stream B. Technically, I should create a separate mixer participant from the announcement participant so that it is clear who is generating the announcement.=20 > What you describe is certainly one way that this scenario could be > reported by the SRC. It is equally possible for the SRC to report the > UA > that provides the automated announcement as another CS participant. And > there are multiple ways that might be accomplished: >=20 > - it could be another participant in CS1. (But if there is no sip > signaling, then that seems problematic.) >=20 > - there could be another CS2 in same CSG with CS1, having the media > player as a participant. (But then its not clear who the other > participant in CS2 would be.) [[hlum]] The model only supports 2 participants in a CS, so it won't work if we use a separate CS to contain the mixer participant. If the mixer participant is handled through a mediactrl server, then technically the mixer participant is part of the signaling via 3pcc and the mixer is indeed part of CS1. >=20 > - we could expand the definition of participation in a CS to encompass > signaling other than sip signaling. I'm open to that, but I think > defining that might be difficult. >=20 > - or we could leave it as you have shown it. From a model perspective > participant C provided MS C "by magic". Its that way because it is by > means that we have not standardized. But the participant info still has > the potential to have all the same info as a CS participant. (Exactly > what is there depends on what info the SRC has available to it.) > "Extra" > information about participant C can also be provided as AppData. [[hlum]] The problem I have with a participant that is not part of any CS is that it can also mean the participant is a non-SIP participant. If our intention is to only support SIP participants only then non-CS participant becomes invalid. >=20 > Thanks, > Paul >=20 >=20 >=20 > On 1/26/2011 4:27 PM, Henry Lum wrote: > > Trying to come up with an instance diagram for what a conference > mixer > > looks like: > > > > +-------------------------------+ > > | Recording Session (RS) | > > +-------------------------------+ > > | > > | > > +-------------------------------+ > > | Communication Session (CS) | > > | Group(CSG) | > > +-------------------------------+ > > | Unique-id1 | > > +-------------------------------+ > > | > > | > > +----------------+ > > | Communication | > > | Session (CS)1 | > > +----------------+ > > | | > > +----------------+ > > | > > |-------------------+ > > | | > > +---------------+ +---------------+ > > | ParticipantA |--+--| ParticipantB | > > +---------------+ | +---------------+ > > | | | > > sends receives sends > > | | | > > +---------------+ | +---------------+ > > |Media Stream A | | |Media Stream B | > > +---------------+ | +---------------+ > > | > > +---------------+ > > |Media Stream C | > > | (mixed stream)| > > +---------------+ > > | > > sends > > | > > +---------------+ > > | ParticipantC | > > | (automated | > > | announcement)| > > +---------------+ > > > > > > Media Stream C is the one that we are interested in and that is the > > recorded stream in the RS. > > > > It looks to me that we need some form of an automated participant > that > > produces the mixed media as well as acting as an automated > participant > > that produces any announcements to the conference mix. This way we > can > > tell who generated the announcements as well as the mix itself, > however, > > I have a the same question as Charles where it is unclear to me > whether > > this automated participant should belong to any CS. > > > > Regards, > > Henry > > > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Charles Eckel (eckelcu) > >> Sent: Wednesday, January 26, 2011 1:56 PM > >> To: siprec@ietf.org > >> Subject: [siprec] metadata model for participant that is not part of > > CS > >> > >> This is to follow up on some questions I raised regarding the > metadata > >> model during the interim meeting Tuesday. > >> My initial concern was that I thought we were allowing media streams > > to > >> be defined without any participant. I now understand that is not the > >> case; rather, a media stream is always associated with at least one > >> participant, but that participant need not necessary be associated > > with > >> the CS. > >> Now I have some concern about participants that are not part of the > > CS. > >> My concern is that the level of metadata we have for such > participants > >> will be inconsistent at best. If the metadata for a non-CS > participant > >> is incomplete, what do we plan to do? > >> Also, I believe there was reference to a document that contains the > >> model and some use cases. Which document is that? > >> > >> Thanks, > >> Charles > >> _______________________________________________ > >> siprec mailing list > >> siprec@ietf.org > >> https://www.ietf.org/mailman/listinfo/siprec > > > > > > --------------------------------------------------------------------- > ---------------------------------------------- > > CONFIDENTIALITY NOTICE: This e-mail and any files attached may > contain confidential and proprietary information of Alcatel-Lucent > and/or its affiliated entities. Access by the intended recipient only > is authorized. Any liability arising from any party acting, or > refraining from acting, on any information contained in this e-mail is > hereby excluded. If you are not the intended recipient, please notify > the sender immediately, destroy the original transmission and its > attachments and do not disclose the contents to any other person, use > it for any purpose, or store or copy the information in any medium. > Copyright in this e-mail and any attachments belongs to Alcatel-Lucent > and/or its affiliated entities. > > > > _______________________________________________ > > 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 =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From eckelcu@cisco.com Thu Jan 27 10:05:03 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C16128C151 for ; Thu, 27 Jan 2011 10:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.323 X-Spam-Level: X-Spam-Status: No, score=-10.323 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgrRK9znDCSV for ; Thu, 27 Jan 2011 10:05:01 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6E3F428C14D for ; Thu, 27 Jan 2011 10:05:01 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4EANZCQU2rR7H+/2dsb2JhbACWIo5bc6Bmm0+FTwSFF4pa Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 27 Jan 2011 18:07:48 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0RI7muS000048; Thu, 27 Jan 2011 18:07:48 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Jan 2011 10:07:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Jan 2011 10:07:46 -0800 Message-ID: In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD0512507C@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] metadata model for participant that is not part of CS Thread-Index: Acu9iqr7ynF7z4Y5QUaRyQBZjCoEsQAaTiAQAAqEFKAAC3gkwA== References: <35BCE99A477D6A4986FB2216D8CF2CFD0512507C@XMB-BGL-417.cisco.com> From: "Charles Eckel (eckelcu)" To: "Ram Mohan R (rmohanr)" , "Elwell, John" , X-OriginalArrivalTime: 27 Jan 2011 18:07:48.0396 (UTC) FILETIME=[1AF11EC0:01CBBE4D] Subject: Re: [siprec] metadata model for participant that is not part of CS X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 18:05:03 -0000 Hi Ram, If all CS participants are required to support the conference event package and provide sufficient info about each non-CS participant in order to be allowed to bring them in, then I am ok with it. My concern is that the SRS will not be able to get sufficient info about non-CS participant in all cases. In such cases, it seems to me the media streams should be associated with the CS participant responsible for the non-CS participant, rather than allowing media from incompletely described non-CS participants to exist on its own. You mention the case of the conference focus, in which everything may be fine, but there are other cases, as mentioned by Jon, for which this may not be the case. Cheers, Charles > -----Original Message----- > From: Ram Mohan R (rmohanr) > Sent: Thursday, January 27, 2011 4:35 AM > To: Elwell, John; Charles Eckel (eckelcu); siprec@ietf.org > Subject: RE: [siprec] metadata model for participant that is not part of CS >=20 > Hi Charles/John, >=20 > In the current model, a media stream is always associated with at least one participant. Here is the > snippet of the associations between CS and Participant and Participant and Media Streams taken from > the draft > https://datatracker.ietf.org/doc/draft-ram-siprec-metadata >=20 > Section 4.3.2 has the associations between CS and Participant > Section 4.4.2 has the associations between media stream and participant >=20 > The current model allows participants who are not part of CS to be part of the model. > A example of such a case is: > - participants in a premixed media stream. The SRC may have knowledge of such Participants, yet not > have any signaling relationship with them. This might arise if one participant in CS is a conf focus. >=20 > In those case, if the metadata for non-CS participants is incomplete, the SRC can use other mechanisms > like subscribing to conference event package to retrieve the information about non-CS participants. >=20 > To summarize the model allows representing of non-CS participants who contribute media to CS. >=20 > Charles, > The use case section is at the end of this document > https://datatracker.ietf.org/doc/draft-ram-siprec-metadata >=20 > Please note the case where Focus is acting as SRC is simpler as all participants of conference which > are connected to focus will in turn become participants of CS too. >=20 > Thanks, > Ram >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > > Sent: Thursday, January 27, 2011 1:09 PM > > To: Charles Eckel (eckelcu); siprec@ietf.org > > Subject: Re: [siprec] metadata model for participant that is not part > > of CS > > > > I am starting to see Charles's point. For a participant behind a > > bridge, you don't really know what media he is contributing or what > > media he is receiving. All you know for certain is that the bridge is a > > participant. Perhaps we could assign multiple user identities to a > > bridge participant, thereby reflecting users behind the bridge that may > > or may not be contributing to the media the bridge sends and may or may > > not be recipients of media the bridge receives. > > > > Note that the model when the SRC is at the bridge, rather than outside > > the bridge, is quite different. Also the model where the bridge is > > switching, rather than mixing, might be different. > > > > John (as individual) > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu) > > > Sent: 26 January 2011 18:56 > > > To: siprec@ietf.org > > > Subject: [siprec] metadata model for participant that is not > > > part of CS > > > > > > This is to follow up on some questions I raised regarding the > > metadata > > > model during the interim meeting Tuesday. > > > My initial concern was that I thought we were allowing media > > > streams to > > > be defined without any participant. I now understand that is not the > > > case; rather, a media stream is always associated with at least one > > > participant, but that participant need not necessary be > > > associated with > > > the CS. > > > Now I have some concern about participants that are not part > > > of the CS. > > > My concern is that the level of metadata we have for such > > participants > > > will be inconsistent at best. If the metadata for a non-CS > > participant > > > is incomplete, what do we plan to do? > > > Also, I believe there was reference to a document that contains the > > > model and some use cases. Which document is that? > > > > > > Thanks, > > > Charles > > > _______________________________________________ > > > 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 From pkyzivat@cisco.com Thu Jan 27 10:54:38 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C83483A69D8 for ; Thu, 27 Jan 2011 10:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.517 X-Spam-Level: X-Spam-Status: No, score=-110.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gTiaaeWECm1 for ; Thu, 27 Jan 2011 10:54:37 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8992D3A684B for ; Thu, 27 Jan 2011 10:54:29 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4EAI5OQU1AZnwM/2dsb2JhbACWIo5bc6Bum1OFTwSFF4cQg0Q Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 27 Jan 2011 18:57:33 +0000 Received: from [10.86.250.39] (bxb-vpn3-551.cisco.com [10.86.250.39]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0RIvX2f013100 for ; Thu, 27 Jan 2011 18:57:33 GMT Message-ID: <4D41C01C.4050205@cisco.com> Date: Thu, 27 Jan 2011 13:57:32 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: siprec@ietf.org References: <35BCE99A477D6A4986FB2216D8CF2CFD0512507C@XMB-BGL-417.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] metadata model for participant that is not part of CS X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 18:54:38 -0000 Charles, I don't think we will be able (or should try) to design this so that everything the SRC specifies is guaranteed to be as complete as you wish it to be. At the end of the day, the SRC will have to do what it can, and some will be better at it than others. If the SRC you have chosen isn't supplying the information it could have and wish it had, then you can complain and request upgrades, or you can choose a different product. As long as we have sufficient expressiveness to describe things as you wish for any given case then I think we are good. Lets ensure we can at least do that. BTW, this is exactly the sort of discussion I have been hoping we would have over the model. I expected it would happen quite some time ago. But better now than never. Thanks, Paul On 1/27/2011 1:07 PM, Charles Eckel (eckelcu) wrote: > Hi Ram, > > If all CS participants are required to support the conference event > package and provide sufficient info about each non-CS participant in > order to be allowed to bring them in, then I am ok with it. My concern > is that the SRS will not be able to get sufficient info about non-CS > participant in all cases. In such cases, it seems to me the media > streams should be associated with the CS participant responsible for the > non-CS participant, rather than allowing media from incompletely > described non-CS participants to exist on its own. > You mention the case of the conference focus, in which everything may be > fine, but there are other cases, as mentioned by Jon, for which this may > not be the case. > > Cheers, > Charles > > > >> -----Original Message----- >> From: Ram Mohan R (rmohanr) >> Sent: Thursday, January 27, 2011 4:35 AM >> To: Elwell, John; Charles Eckel (eckelcu); siprec@ietf.org >> Subject: RE: [siprec] metadata model for participant that is not part > of CS >> >> Hi Charles/John, >> >> In the current model, a media stream is always associated with at > least one participant. Here is the >> snippet of the associations between CS and Participant and Participant > and Media Streams taken from >> the draft >> https://datatracker.ietf.org/doc/draft-ram-siprec-metadata >> >> Section 4.3.2 has the associations between CS and Participant >> Section 4.4.2 has the associations between media stream and > participant >> >> The current model allows participants who are not part of CS to be > part of the model. >> A example of such a case is: >> - participants in a premixed media stream. The SRC may have knowledge > of such Participants, yet not >> have any signaling relationship with them. This might arise if one > participant in CS is a conf focus. >> >> In those case, if the metadata for non-CS participants is incomplete, > the SRC can use other mechanisms >> like subscribing to conference event package to retrieve the > information about non-CS participants. >> >> To summarize the model allows representing of non-CS participants who > contribute media to CS. >> >> Charles, >> The use case section is at the end of this document >> https://datatracker.ietf.org/doc/draft-ram-siprec-metadata >> >> Please note the case where Focus is acting as SRC is simpler as all > participants of conference which >> are connected to focus will in turn become participants of CS too. >> >> Thanks, >> Ram >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Elwell, John >>> Sent: Thursday, January 27, 2011 1:09 PM >>> To: Charles Eckel (eckelcu); siprec@ietf.org >>> Subject: Re: [siprec] metadata model for participant that is not > part >>> of CS >>> >>> I am starting to see Charles's point. For a participant behind a >>> bridge, you don't really know what media he is contributing or what >>> media he is receiving. All you know for certain is that the bridge > is a >>> participant. Perhaps we could assign multiple user identities to a >>> bridge participant, thereby reflecting users behind the bridge that > may >>> or may not be contributing to the media the bridge sends and may or > may >>> not be recipients of media the bridge receives. >>> >>> Note that the model when the SRC is at the bridge, rather than > outside >>> the bridge, is quite different. Also the model where the bridge is >>> switching, rather than mixing, might be different. >>> >>> John (as individual) >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel > (eckelcu) >>>> Sent: 26 January 2011 18:56 >>>> To: siprec@ietf.org >>>> Subject: [siprec] metadata model for participant that is not >>>> part of CS >>>> >>>> This is to follow up on some questions I raised regarding the >>> metadata >>>> model during the interim meeting Tuesday. >>>> My initial concern was that I thought we were allowing media >>>> streams to >>>> be defined without any participant. I now understand that is not > the >>>> case; rather, a media stream is always associated with at least > one >>>> participant, but that participant need not necessary be >>>> associated with >>>> the CS. >>>> Now I have some concern about participants that are not part >>>> of the CS. >>>> My concern is that the level of metadata we have for such >>> participants >>>> will be inconsistent at best. If the metadata for a non-CS >>> participant >>>> is incomplete, what do we plan to do? >>>> Also, I believe there was reference to a document that contains > the >>>> model and some use cases. Which document is that? >>>> >>>> Thanks, >>>> Charles >>>> _______________________________________________ >>>> 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 > From Henry.Lum@alcatel-lucent.com Mon Jan 31 14:14:58 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FF453A6C26 for ; Mon, 31 Jan 2011 14:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.892 X-Spam-Level: X-Spam-Status: No, score=-5.892 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZsUgrUDez2o for ; Mon, 31 Jan 2011 14:14:52 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 854503A67F7 for ; Mon, 31 Jan 2011 14:14:52 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p0VMI7UA004001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 31 Jan 2011 16:18:07 -0600 (CST) Received: from relay-out2.dc (relay-out2.dc.genesyslab.com [172.22.68.188]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0VMI47D027277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 31 Jan 2011 16:18:06 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc (8.13.8+Sun/8.13.8) with ESMTP id p0VMHub9006282 for ; Mon, 31 Jan 2011 14:18:04 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Jan 2011 14:16:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBC194.8608A1D0" Date: Mon, 31 Jan 2011 14:16:34 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF7406A1EE1B@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: mechansim for requesting no-record for recording aware UA Thread-Index: AcvBlIU5iYBkZCxSQi+CwgmojsscLQ== From: "Henry Lum" To: X-OriginalArrivalTime: 31 Jan 2011 22:16:35.0847 (UTC) FILETIME=[860C6170:01CBC194] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [siprec] mechansim for requesting no-record for recording aware UA X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 22:14:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC194.8608A1D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is one of the issues from the interim call. =20 In order for a recording-aware UA to request that a call not to be recorded, there are 3 proposed mechanisms. I want to get feedback on which mechanism is most appropriate to meet REQ-017 and REQ-018: =20 1) Use caller preference to request that a call not to be recorded =20 For example, Reject-Contact: *;sip.recorded=20 =20 For a UA to request that a call not to be recorded. When the call is being recorded, use the feature tag sip.recorded to indicate that the call is being recorded. The mechanism is optional so this preference may not be honored all the time. Also, the mechanism in Reject-Contact would prevent the call from connecting there are no contacts that would not record the call. =20 2) Specify a new SIP header to indicate recording preference =20 Define a new option tag called no-record and use a new SIP header to indicate recording preference in a new SIP header. =20 For example, Record-Preference: record / no-record-reject / no-record-accept =20 record means that the caller is requesting the call to be recorded no-record-reject means that the caller does not wish to connect the call if the call must be recorded. no-record-accept means that the caller does not wish to be recorded but may establish the call is recording is enabled. =20 When the call is recorded, use the feature tag sip.recorded to indicate that the call is being recorded. =20 3) Define a new SDP attribute to request for either a session or media stream not to be recorded.=20 =20 This one is suggested during the interim call and allows the caller to indicate recording preference using a session-level or media-level attribute. We can define two attributes: =20 a=3Drecordpref:[preference] preference =3D "record" / "no-record-reject" / "no-record-accept" =20 The meaning of the preferences are the same as 2) above. =20 a=3Drecord:[state] state =3D "active" / "inactive" =20 The first attribute is used by the user agent who wishes to indicate the preference for recording the session. The second attribute is used to indicate whether recording is actually active or inactive. This mechanism also allows a user agent is allowed to send a reINVITE in the middle of the call to change the recording preference.=20 =20 =20 =20 Regards, Henry =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 ------_=_NextPart_001_01CBC194.8608A1D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is one of the issues from the interim call.

 

In order for a recording-aware UA to request that a = call not to be recorded, there are 3 proposed mechanisms. I want to get feedback o= n which mechanism is most appropriate to meet REQ-017 and REQ-018:

 

1)=       Use caller preference to request that a call not = to be recorded

 

For example,

Reject-Contact: *;sip.recorded

 

For a UA to request that a call not to be recorded. = When the call is being recorded, use the feature tag sip.recorded to indicate that= the call is being recorded. The mechanism is optional so this preference may = not be honored all the time. Also, the mechanism in Reject-Contact would prevent= the call from connecting there are no contacts that would not record the call= =2E

 

2)=       Specify a new SIP header to indicate recording preference

 

Define a new option tag called no-record and use a n= ew SIP header to indicate recording preference in a new SIP header.

 

For example,

Record-Preference: record / no-record-reject / no-re= cord-accept

 

record means that the caller is requesting the call = to be recorded

no-record-reject means that the caller does not wish= to connect the call if the call must be recorded.

no-record-accept means that the caller does not wish= to be recorded but may establish the call is recording is enabled.

 

When the call is recorded, use the feature tag sip.r= ecorded to indicate that the call is being recorded.

 

3)=       Define a new SDP attribute to request for either = a session or media stream not to be recorded.

 

This one is suggested during the interim call and al= lows the caller to indicate recording preference using a session-level or media-le= vel attribute. We can define two attributes:

 

a=3Drecordpref:[preference]

preference =3D “record” / “no-reco= rd-reject” / “no-record-accept”

 

The meaning of the preferences are the same as 2) ab= ove.

 

a=3Drecord:[state]

state =3D “active”  / “inacti= ve”

 

The first attribute is used by the user agent who wi= shes to indicate the preference for recording the session. The second attribute i= s used to indicate whether recording is actually active or inactive. This mechan= ism also allows a user agent is allowed to send a reINVITE in the middle of t= he call to change the recording preference.

 

 

 

Regards,

Henry

 


CONFIDENTIALITY NOTICE: This e-mai= l and any files attached may contain confidential and proprietary informa= tion of Alcatel-Lucent and/or its affiliated entities. Access by the inte= nded recipient only is authorized. Any liability arising from any party a= cting, or refraining from acting, on any information contained in this e-= mail is hereby excluded. If you are not the intended recipient, please no= tify the sender immediately, destroy the original transmission and its at= tachments and do not disclose the contents to any other person, use it fo= r any purpose, or store or copy the information in any medium. Copyright = in this e-mail and any attachments belongs to Alcatel-Lucent and/or its a= ffiliated entities. ------_=_NextPart_001_01CBC194.8608A1D0-- From Dave.d.Smith@alcatel-lucent.com Mon Jan 31 15:23:26 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 062563A6B26 for ; Mon, 31 Jan 2011 15:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.533 X-Spam-Level: X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skRHmohmlnvt for ; Mon, 31 Jan 2011 15:23:23 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 771123A6848 for ; Mon, 31 Jan 2011 15:23:22 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p0VNPppe012643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Jan 2011 17:25:52 -0600 (CST) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [172.22.70.114]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0VNPoaR027771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 31 Jan 2011 17:25:51 -0600 Received: from g3.genesyslab.com (g3.us.int.genesyslab.com [192.168.88.58]) by relay-out1.wc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id p0VNPm9n004531; Mon, 31 Jan 2011 15:25:48 -0800 (PST) Received: from SARUMAN.us.int.genesyslab.com ([192.168.20.90]) by g3.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Jan 2011 15:25:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Jan 2011 15:25:48 -0800 Message-ID: In-Reply-To: <4D417365.60205@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Proposed change to REQ-017 concerning cancellation Thread-Index: Acu+JlmOZ0ctNENgS5KU4xNBuEmejgDcvPpw References: <4D417365.60205@cisco.com> From: "Dave Smith" To: "Paul Kyzivat" , , "Alissa Cooper" X-OriginalArrivalTime: 31 Jan 2011 23:25:49.0520 (UTC) FILETIME=[31D49500:01CBC19E] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 23:23:26 -0000 I agree that we do not need to consider Discarding the recording file since Discarding is a policy matter, is about SRS functionality, and is outside our scope. However, I do think we should include functionality to support an autonomous UA request to Stop recording (and BTW, probably even a UA request to Start recording could be supported as well). =20 As Alissa said, and I agree that REQ-001 to REQ-011 could be used to Stop a recording. For example, in the Contact Center use case, if developed appropriately, a Customer could verbally ask an Agent to stop the recording and the Agent could then send a signal to the SRC to Stop recording. And probably similar functionality could be done by an IVR (e.g., "Select 3 to terminate recording"). However, I believe this could/should be done more elegantly by allowing a UA to request to Stop recording autonomously. =20 If you disagree, then it makes no sense to keep REQ-017 at all. =20 If REQ-017 is going to be kept, then it should include "during" as well as "prior to the start of recording." =20 Regards, Dave -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Thursday, January 27, 2011 5:30 AM To: siprec@ietf.org Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation Inline On 1/27/2011 8:02 AM, Alissa Cooper wrote: > As written, I think this use case (and the revised REQ-017) is still > slightly ambiguous. There seem to be three cases: > > (1) Recording starts. Customer requests that recording be stopped. > Recording stops. > (2) Recording starts. Customer requests that recording be stopped and > discarded. Recording stops. Recording is discarded. > (3) Recording starts. Customer requests that recording be stopped and > discarded. Recording stops but recording is not discarded. > > I think (1) is already covered between REQ-001 and REQ-011. > > I think (2) is by and large what we were discussing when we were talking > about ditching REQ-015 and REQ-016. As noted during the virtual interim > day 1, whether the SRS actually discards the recording depends on policy > set by the SRC, which we had said was out of scope. > > BUT it sort of sounded like case (3) might be of interest -- i.e., that > having the ability for an SRC to send an indication to the SRS of the > customer's preference that the recording be discarded, even if that > preference will not always be honored, is something that we may want to > support. If that's the case, it might merit its own requirement ("The > mechanism MUST provide a means for an SRC to indicate to an SRS a > preference to discard a recording" or something like that). There is a fundamental difference between 1 and 2/3. The customer (I assume this to be a participant not in control of the=20 SRC) can *ask* that the recording be discarded. But he can not be=20 certain that is has been. Similarly, the agent (or any participant that *is* in control of the=20 SRC) could (if we provide a suitable mechanism) *ask* the SRS to discard the recording. But again he cannot be certain it has been. We could even provide a mechanism to ACK/NACK a request to discard a=20 recording. That could allow the SRC a bit more knowledge, but the SRS=20 could still by lying. Only the SRS *knows* if the recording has been discarded. Whether it=20 does so when asked will depend upon its operating policies, which could=20= include policies that violate the law. So, given all of that, is it worth the trouble to include a mechanism to request the discard of a recording, and to ACK/NACK that request??? If that is felt to be important, then it will be a bit of work, because=20= we will need to define *what* is to be discarded, and that is non-trivial. I mentioned on the list the mechanism that exists in some email systems=20= to "retract" an email. AFAIK this very rarely "works" - it often results in all the recipients getting another email saying "John Smith would=20 like to recall email xyz", but *does not* result in the intended result. I think requesting that a recording be discarded falls into he same=20 category. If you seriously want to ensure that a recording has been=20 discarded, then I suggest you hire a lawyer and file a lawsuit. Thanks, Paul > Alissa > > On Jan 27, 2011, at 7:03 AM, Elwell, John wrote: > >> Just changed the subject line so that people concerned will notice it. >> >> John >> >>> -----Original Message----- >>> From: Dave Smith [mailto:Dave.d.Smith@alcatel-lucent.com] >>> Sent: 26 January 2011 21:22 >>> To: Elwell, John; siprec@ietf.org >>> Subject: RE: [siprec] Minutes day 1 >>> >>> Hi, >>> Here is my input to my Action Item related to REQ-015/016 - >>> to raise on >>> the list any fresh requirements concerning what CS >>> participants might be >>> able to request regarding "canceling" and/or "discarding" recording. >>> >>> It seems that REQ-017 already covers the basic idea; however, >>> REQ-017 is >>> only valid " prior to the start of recording ". My concern >>> was for the >>> mechanism to also work "during" recording. >>> Therefore, my proposal is to consider to update REQ-017 as follows: >>> >>> Currently it reads: >>> o REQ-017 The mechanism MUST support a means for an authorized >>> participant involved in a CS to request, prior to the start of >>> recording, that the CS not be recorded >>> >>> Change to: >>> o REQ-017 The mechanism MUST support a means for an authorized >>> participant involved in a CS to request, during or prior >>> to the start >>> of >>> recording, that the CS not be recorded >>> >>> >>> Use Case supporting this change: >>> 1. Customer calls a contact center >>> 2. Agent answers the phone >>> 3. Customer starts discussing their issue with the Agent >>> 4. Customer realizes that the call is being recorded (e.g., >>> they hear a "beep" tone indicating that the call is currently being >>> recorded) >>> 5. Customer decides that they do not want the call to be >>> recorded >>> 6. Customer requests that the call not be recorded (e.g., >>> customer phone application is used to send a signal within the CS that >>> can be received/interpreted by the SRC) >>> 7. The SRC stops the recording >>> Also note the following that could further be done, if an >>> implementation >>> desires (no req'ts needed): >>> Optional: 8. The SRC sends metadata to the SRS indicating that >>> the Customer requested that the call NOT be recorded >>> Optional: 9. The SRS uses its internal policy procedures and >>> decides to delete the recorded audio file from the Customer recording >>> >>> >>> >>> Let me know your inputs and if this change makes sense. >>> >>> >>> Regards, >>> Dave >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org] On Behalf >>> Of Elwell, John >>> Sent: Tuesday, January 25, 2011 2:24 PM >>> To: siprec@ietf.org >>> Subject: [siprec] Minutes day 1 >>> >>> Minutes of the SIPREC WG Interim Virtual Meeting >>> 2011-01-25, 15.00-17.00 GMT/UTC and >>> 2011-01-25, 14.00-16.00 GMT/UTC >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> Meeting chaired by Brian Rosen and John Elwell. >>> >>> Participants (session 1): Brian Rosen, John Elwell, Ken Rehor, Leon >>> Portman, Henry Lum, Ram >>> Mohen, Andy Hutton, Alan Johnston, Gonzalo Camarillo, Paul >>> Kyzivat, Dave >>> Smith, Parthasarathi, Dan Romascanu, Alissa Cooper, Charles Eckel >>> >>> Minutes produced by John Elwell. >>> >>> Webex chat: See end of these minutes. Jabber was not used. >>> >>> Recording day 1: >>> https://workgreen.webex.com/workgreen/ldr.php?AT=3Dpb&SP=3DMC&rID=3D >>> 8263017&rK >>> ey=3D19329980a044b45b >>> >>> Meeting started at 15.02. >>> >>> Topic - Administrivia (chairs) >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >>> Slides: http://kenrehor.com/ietf/siprec/IETF79.2/Chairs.pdf >>> >>> No changes to published agenda. >>> >>> >>> Topic - Requirements (Ken Rehor) >>> draft-ietf-siprec-req-06 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >>> Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-req/ >>> Slides: >>> http://kenrehor.com/ietf/siprec/IETF79.2/IETF-79.2-SIPREC-Req- >> 2011-01-25 >>> .pdf >>> >>> Slide 4 - proposal to delete REQ-015/016. It was noted that these >>> requirements talk about "cancel and discard". After some discussion, >>> there seemed to be agreement that the "cancel" part was >>> covered by other >>> requirements (e.g., you can pause and not resume, effectively >>> cancelling). So the main issue concerned the "discard" part. It was >>> noted that previous agreements relating to privacy had reached the >>> conclusion that the retention of recordings is an issue for >>> the SRS, and >>> outside the scope of SIPREC. There was no objection to >>> deleting the two >>> requirements. >>> >>> Although the main focus of the requirements is on what happens on the >>> SRC-SRS interface, Dave Smith brought up the question of whether a >>> participant, whose SIP UA might not be collocated with the SRC, can >>> request the pausing / stopping of a recording, or even >>> request deletion >>> of the recording. This would be a requirement impacting the CS, as >>> opposed to the RS, and it was noted that none of the solution work has >>> touched on that (although the earlier draft from Alan >>> Johnston did have >>> provision for an indication on the CS signalling path that >>> recording is >>> taking place, but this was not brought forward into the >>> present protocol >>> draft). Dave was invited to raise on the list any fresh requirements >>> concerning what CS participants might be able to request. >>> >>> Slide 5 - proposed new requirement on multiple media streams for the >>> same media type. It was observed that REQ-010 was probably intended to >>> cover this case, and Ken will propose words to enhance REQ-010 to make >>> it clearer. >>> >>> Slide 6 - removal of REQ-021. There was no objection to removal. >>> >>> Ken will try to seek resolution of the issues above and then publish >>> -07, which should be very close to being ready to submit to the IESG. >>> >>> >>> Topic - Metadata model (Ram Mohan) >>> draft-ram-siprec-metadata-03 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >>> Draft: https://datatracker.ietf.org/doc/draft-ram-siprec-metadata/ >>> Slides: ???? >>> >>> Slide 4: Ram explained why an association between Media Stream and CS >>> had been introduced, because of the injection of things like music on >>> hold, leading to a media stream without participant. Charles wondered >>> why music on hold could not be considered a participant. Ram and Paul >>> explained there were also conference cases where a participant might >>> host a conference on his device, but those behind the conferencing >>> device might not be considered CS participants. Charles asked why the >>> conference focus could not be considered a participant. Paul explained >>> that the SRC could obtain, using the conference event >>> package, a list of >>> participants from the focus, and those participants would >>> contribute to >>> the media stream, but those participants would not be part of the CS - >>> that would be the role of the focus. Henry thought a mixer might be >>> considered a participant, but Paul explained that if you can obtain a >>> roster of people behind the mixer, those might be considered >>> participants rathe >>> r than the mixer. So there can be participants in the media that are >>> not participants in the CS. Charles was worried that some >>> media streams >>> might not have any identified participants who are generating the >>> stream. Paul explained that, assuming the media from the participants >>> are mixed, you would see one media stream and a list of participants. >>> One participant might be joined to the CS and the others would not be. >>> Paul thinks we need to explore some use cases and see how >>> they would be >>> represented using this model. So if people have particular use cases, >>> make them known and we check how they would be represented. Ram will >>> solicit use cases. Partha also had concerns similar to those >>> of Charles, >>> but Charles was beginning to see how the present model might >>> work if you >>> can get information about non-CS participants who are >>> generating a media >>> stream. Paul pointed out that the model does cater for a participant >>> that is not part of a CS. Charles was invited to post his >>> continued conc >>> erns / scenarios to the list, but Paul thinks the use cases concerned >>> are already covered by the model. >>> >>> Slide 6 (CS Group): Nobody on list had come up with a reason >>> for having >>> more than one CSG associated with a single CS, and the conclusion >>> reached on the list seems to stand. >>> >>> Slide 7 (CS): No comments on CS slide, except that forced >>> deletion is to >>> be removed in line with the requirements discussion. >>> >>> Slide 8 (Participant): Clarified that the multiple AORs are >>> aliases, in >>> the sense of P-Asserted-Identity being able to carry aliases. >>> >>> Concerning the issue of whether participant role is needed as an >>> attribute, Leon suggested it could be done in application data, but >>> asked whether we would then publish some application data dictionary. >>> Paul suggested that application data is just some additional >>> XML in some >>> other namespace, so some other group could get together and define it. >>> Leon was concerned that without some sort of standardization, >>> different >>> vendors would implement it differently. John suggested we >>> need to decide >>> what things are needed by 80% of deployments and standardize those in >>> this group, so if that is the case for participant role, we should >>> standardize it. Partha wanted to include participant role, even though >>> there might be some cases where it is not available. Paul pointed out >>> that we had had considerable list discussion on the difficulties of >>> figuring out the role: UAC/UAS is transaction specific, >>> inbound/outbound >>> is problematic, and incoming/outgoing, whilst it might work in some >>> cases, it w >>> ill not always work. Perhaps those focused on call centres >>> can say what >>> might/might not work. In conclusion, this has to be taken back to the >>> list. Without repeating the old arguments, those wanting to include >>> participant role should indicate what are the likely mechanisms that >>> might support it. >>> >>> Slide 10 (Media Stream): How to model media streams that are not >>> recorded (rejected by SRS or no capability at SRS). Dave thought was >>> important that you have some information in the metadata that >>> there was >>> media that was available for recording but couldn't be recorded, but >>> there are two cases: where you don't want to record, or where >>> because of >>> a temporary limitation you are unable to record but might >>> want to record >>> later. Paul agreed, but was concerned about the details, although that >>> is very much down to the mechanism, e.g., does the SRC need to keep >>> offering the stream? >>> >>> Partha asked a question on start time and end time. Ram clarified this >>> is these are start and end times of the CS media. It was pointed out >>> that we have wall clock time in the metadata, and other times can be >>> relative. Leon suggested there may be a need to retransmit wall clock >>> time occasionally, to compensate for drift. >>> >>> Henry asked whether media stream reference should be part of the >>> mechanism rather than an attribute. >>> >>> Slide 10 (Application data): Leon agreed with the extensible approach, >>> based on different namespaces. Paul said that he would be tempted to >>> stop calling it application data and call it extension data. >>> John (from >>> the floor) questioned whether it really is an object, or just >>> attributes >>> of other objects. Paul said it was just an artefact of how >>> the model is >>> drawn, but in the solution it would just be extensibility data. The >>> authors will rework this with these comments in mind. >>> >>> On next steps, people are asked to review and submit further >>> comments on >>> -03, and -04 will be produced in due course, after which we might be >>> consider adoption as a WG item. In particular, we need closure on the >>> long discussion of media stream relationships. >>> >>> >>> Topic - Protocol (Henry Lum / Leon Portman) >>> draft-portman-siprec-protocol-02 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >>> Draft: https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ >>> Slides: http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20- >>> %20virtual%20interim%20Dec%2016%202010.pdf >>> >>> Slide 4 (Persistent recording): Leon pointed out that the >>> whole idea of >>> persistent recording is not to spend time negotiating m-lines >>> when a CS >>> starts - so he prefers the second option on the slide. For SRCs that >>> support a large number of parallel CSs, the SRC could pre-negotiate a >>> large number of m-lines (perhaps based on licensing), rather like >>> provisioning trunks. Paul felt that the other option should >>> be kept open >>> - a slight delay in negotiating a new m-line could be handled by >>> transmitting the data slightly delayed, without losing any. Henry also >>> mentioned the possibility of the offer-answer failing. It was >>> questioned >>> whether there needs to be something in the protocol to indicate the >>> delay. This issue should be brought to the list. >>> >>> >>> Day 1 wrap-up >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> It was agreed that on the second day we will start by completing the >>> Protocol topic and then do the metadata format topic. >>> >>> The meeting was closed at 17.00. >>> >>> >>> Day 1 chat log >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >>> January 25, 2011 3:19:58 PM from Alissa Cooper >>> to Everyone: I'm not in a place where I can speak in the audio, but I >>> think we decided not to have requirements related to what >>> happens to the >>> recording after it has been made. >>> >>> January 25, 2011 3:30:32 PM from Alissa Cooper >>> to Everyone: it seems like there are cases where the hints are >>> valuable even if they aren't always honoured >>> >>> January 25, 2011 3:39:51 PM from Alissa Cooper >>> to Everyone: it's old, I'll take it to the list >>> >>> January 25, 2011 4:59:32 PM from Kenneth Rehor >>> to Everyone: Unfortunately I have to drop off now. TTY tomorrow. >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >>> >>> -------------------------------------------------------------- >>> ----------------------------------------------------- >>> CONFIDENTIALITY NOTICE: This e-mail and any files attached >>> may contain confidential and proprietary information of >>> Alcatel-Lucent and/or its affiliated entities. Access by the >>> intended recipient only is authorized. Any liability arising >>> from any party acting, or refraining from acting, on any >>> information contained in this e-mail is hereby excluded. If >>> you are not the intended recipient, please notify the sender >>> immediately, destroy the original transmission and its >>> attachments and do not disclose the contents to any other >>> person, use it for any purpose, or store or copy the >>> information in any medium. Copyright in this e-mail and any >>> attachments belongs to Alcatel-Lucent and/or its affiliated entities. >>> >>> >> _______________________________________________ >> 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 =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From pkyzivat@cisco.com Mon Jan 31 18:18:09 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82E33A6B33 for ; Mon, 31 Jan 2011 18:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.17 X-Spam-Level: X-Spam-Status: No, score=-110.17 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNnIDhp563m9 for ; Mon, 31 Jan 2011 18:18:08 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 858443A68EA for ; Mon, 31 Jan 2011 18:18:08 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANv8Rk1AZnwM/2dsb2JhbACke3OgVJs7hU4EhROHDoNF Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 01 Feb 2011 02:21:24 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p112LNac023931 for ; Tue, 1 Feb 2011 02:21:23 GMT Message-ID: <4D476E23.5060104@cisco.com> Date: Mon, 31 Jan 2011 21:21:23 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: siprec@ietf.org References: <059AF07365DC474393A19A3AF187DF7406A1EE1B@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF7406A1EE1B@NAHALD.us.int.genesyslab.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [siprec] mechansim for requesting no-record for recording aware UA X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 02:18:09 -0000 Just to be clear, this is discussing how this request is indicated in the *CS*, right? I *think* I prefer option 3 (in SDP) for the flexibility it gives and because fundamentally this is about media. However that probably won't say anything about whether *metadata* about the call is recorded. Do we care about that? Thanks, Paul On 1/31/2011 5:16 PM, Henry Lum wrote: > This is one of the issues from the interim call. > > In order for a recording-aware UA to request that a call not to be > recorded, there are 3 proposed mechanisms. I want to get feedback on > which mechanism is most appropriate to meet REQ-017 and REQ-018: > > 1)Use caller preference to request that a call not to be recorded > > For example, > > Reject-Contact: *;sip.recorded > > For a UA to request that a call not to be recorded. When the call is > being recorded, use the feature tag sip.recorded to indicate that the > call is being recorded. The mechanism is optional so this preference may > not be honored all the time. Also, the mechanism in Reject-Contact would > prevent the call from connecting there are no contacts that would not > record the call. > > 2)Specify a new SIP header to indicate recording preference > > Define a new option tag called no-record and use a new SIP header to > indicate recording preference in a new SIP header. > > For example, > > Record-Preference: record / no-record-reject / no-record-accept > > record means that the caller is requesting the call to be recorded > > no-record-reject means that the caller does not wish to connect the call > if the call must be recorded. > > no-record-accept means that the caller does not wish to be recorded but > may establish the call is recording is enabled. > > When the call is recorded, use the feature tag sip.recorded to indicate > that the call is being recorded. > > 3)Define a new SDP attribute to request for either a session or media > stream not to be recorded. > > This one is suggested during the interim call and allows the caller to > indicate recording preference using a session-level or media-level > attribute. We can define two attributes: > > a=recordpref:[preference] > > preference = “record” / “no-record-reject” / “no-record-accept” > > The meaning of the preferences are the same as 2) above. > > a=record:[state] > > state = “active” / “inactive” > > The first attribute is used by the user agent who wishes to indicate the > preference for recording the session. The second attribute is used to > indicate whether recording is actually active or inactive. This > mechanism also allows a user agent is allowed to send a reINVITE in the > middle of the call to change the recording preference. > > Regards, > > Henry > > > > CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain > confidential and proprietary information of Alcatel-Lucent and/or its > affiliated entities. Access by the intended recipient only is > authorized. Any liability arising from any party acting, or refraining > from acting, on any information contained in this e-mail is hereby > excluded. If you are not the intended recipient, please notify the > sender immediately, destroy the original transmission and its > attachments and do not disclose the contents to any other person, use it > for any purpose, or store or copy the information in any medium. > Copyright in this e-mail and any attachments belongs to Alcatel-Lucent > and/or its affiliated entities. > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@cisco.com Mon Jan 31 18:21:59 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 184DA3A6B33 for ; Mon, 31 Jan 2011 18:21:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.467 X-Spam-Level: X-Spam-Status: No, score=-110.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iC2jIDNyMow for ; Mon, 31 Jan 2011 18:21:56 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 46D0B3A68EA for ; Mon, 31 Jan 2011 18:21:55 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0DAAb+Rk2Q/khNgWdsb2JhbACWG45gFQEBFiIkiCuYLJs7gniCVgSFE4cOg0U Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 01 Feb 2011 02:25:10 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p112P9CV026655; Tue, 1 Feb 2011 02:25:09 GMT Message-ID: <4D476F05.8060506@cisco.com> Date: Mon, 31 Jan 2011 21:25:09 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Dave Smith References: <4D417365.60205@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 02:21:59 -0000 I agree that all of this *can* be done. My main question is whether any real user would believe it is *actually* being done? There really is no way to *verify* that the recording isn't happening. But if this is thought to be useful it certainly can be done. Thanks, Paul On 1/31/2011 6:25 PM, Dave Smith wrote: > I agree that we do not need to consider Discarding the recording file > since Discarding is a policy matter, is about SRS functionality, and is > outside our scope. > However, I do think we should include functionality to support an > autonomous UA request to Stop recording (and BTW, probably even a UA > request to Start recording could be supported as well). > > As Alissa said, and I agree that REQ-001 to REQ-011 could be used to > Stop a recording. For example, in the Contact Center use case, if > developed appropriately, a Customer could verbally ask an Agent to stop > the recording and the Agent could then send a signal to the SRC to Stop > recording. And probably similar functionality could be done by an IVR > (e.g., "Select 3 to terminate recording"). However, I believe this > could/should be done more elegantly by allowing a UA to request to Stop > recording autonomously. > > If you disagree, then it makes no sense to keep REQ-017 at all. > If REQ-017 is going to be kept, then it should include "during" as well > as "prior to the start of recording." > > Regards, > Dave > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Thursday, January 27, 2011 5:30 AM > To: siprec@ietf.org > Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation > > Inline > > On 1/27/2011 8:02 AM, Alissa Cooper wrote: >> As written, I think this use case (and the revised REQ-017) is still >> slightly ambiguous. There seem to be three cases: >> >> (1) Recording starts. Customer requests that recording be stopped. >> Recording stops. >> (2) Recording starts. Customer requests that recording be stopped and >> discarded. Recording stops. Recording is discarded. >> (3) Recording starts. Customer requests that recording be stopped and >> discarded. Recording stops but recording is not discarded. >> >> I think (1) is already covered between REQ-001 and REQ-011. >> >> I think (2) is by and large what we were discussing when we were > talking >> about ditching REQ-015 and REQ-016. As noted during the virtual > interim >> day 1, whether the SRS actually discards the recording depends on > policy >> set by the SRC, which we had said was out of scope. >> >> BUT it sort of sounded like case (3) might be of interest -- i.e., > that >> having the ability for an SRC to send an indication to the SRS of the >> customer's preference that the recording be discarded, even if that >> preference will not always be honored, is something that we may want > to >> support. If that's the case, it might merit its own requirement ("The >> mechanism MUST provide a means for an SRC to indicate to an SRS a >> preference to discard a recording" or something like that). > > There is a fundamental difference between 1 and 2/3. > > The customer (I assume this to be a participant not in control of the > SRC) can *ask* that the recording be discarded. But he can not be > certain that is has been. > > Similarly, the agent (or any participant that *is* in control of the > SRC) could (if we provide a suitable mechanism) *ask* the SRS to discard > > the recording. But again he cannot be certain it has been. > > We could even provide a mechanism to ACK/NACK a request to discard a > recording. That could allow the SRC a bit more knowledge, but the SRS > could still by lying. > > Only the SRS *knows* if the recording has been discarded. Whether it > does so when asked will depend upon its operating policies, which could > include policies that violate the law. > > So, given all of that, is it worth the trouble to include a mechanism to > > request the discard of a recording, and to ACK/NACK that request??? > > If that is felt to be important, then it will be a bit of work, because > we will need to define *what* is to be discarded, and that is > non-trivial. > > I mentioned on the list the mechanism that exists in some email systems > to "retract" an email. AFAIK this very rarely "works" - it often results > > in all the recipients getting another email saying "John Smith would > like to recall email xyz", but *does not* result in the intended result. > > I think requesting that a recording be discarded falls into he same > category. If you seriously want to ensure that a recording has been > discarded, then I suggest you hire a lawyer and file a lawsuit. > > Thanks, > Paul > >> Alissa >> >> On Jan 27, 2011, at 7:03 AM, Elwell, John wrote: >> >>> Just changed the subject line so that people concerned will notice > it. >>> >>> John >>> >>>> -----Original Message----- >>>> From: Dave Smith [mailto:Dave.d.Smith@alcatel-lucent.com] >>>> Sent: 26 January 2011 21:22 >>>> To: Elwell, John; siprec@ietf.org >>>> Subject: RE: [siprec] Minutes day 1 >>>> >>>> Hi, >>>> Here is my input to my Action Item related to REQ-015/016 - >>>> to raise on >>>> the list any fresh requirements concerning what CS >>>> participants might be >>>> able to request regarding "canceling" and/or "discarding" recording. >>>> >>>> It seems that REQ-017 already covers the basic idea; however, >>>> REQ-017 is >>>> only valid " prior to the start of recording ". My concern >>>> was for the >>>> mechanism to also work "during" recording. >>>> Therefore, my proposal is to consider to update REQ-017 as follows: >>>> >>>> Currently it reads: >>>> o REQ-017 The mechanism MUST support a means for an authorized >>>> participant involved in a CS to request, prior to the start of >>>> recording, that the CS not be recorded >>>> >>>> Change to: >>>> o REQ-017 The mechanism MUST support a means for an authorized >>>> participant involved in a CS to request, during or prior >>>> to the start >>>> of >>>> recording, that the CS not be recorded >>>> >>>> >>>> Use Case supporting this change: >>>> 1. Customer calls a contact center >>>> 2. Agent answers the phone >>>> 3. Customer starts discussing their issue with the Agent >>>> 4. Customer realizes that the call is being recorded (e.g., >>>> they hear a "beep" tone indicating that the call is currently being >>>> recorded) >>>> 5. Customer decides that they do not want the call to be >>>> recorded >>>> 6. Customer requests that the call not be recorded (e.g., >>>> customer phone application is used to send a signal within the CS > that >>>> can be received/interpreted by the SRC) >>>> 7. The SRC stops the recording >>>> Also note the following that could further be done, if an >>>> implementation >>>> desires (no req'ts needed): >>>> Optional: 8. The SRC sends metadata to the SRS indicating that >>>> the Customer requested that the call NOT be recorded >>>> Optional: 9. The SRS uses its internal policy procedures and >>>> decides to delete the recorded audio file from the Customer > recording >>>> >>>> >>>> >>>> Let me know your inputs and if this change makes sense. >>>> >>>> >>>> Regards, >>>> Dave >>>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] On Behalf >>>> Of Elwell, John >>>> Sent: Tuesday, January 25, 2011 2:24 PM >>>> To: siprec@ietf.org >>>> Subject: [siprec] Minutes day 1 >>>> >>>> Minutes of the SIPREC WG Interim Virtual Meeting >>>> 2011-01-25, 15.00-17.00 GMT/UTC and >>>> 2011-01-25, 14.00-16.00 GMT/UTC >>>> =============================================== >>>> Meeting chaired by Brian Rosen and John Elwell. >>>> >>>> Participants (session 1): Brian Rosen, John Elwell, Ken Rehor, Leon >>>> Portman, Henry Lum, Ram >>>> Mohen, Andy Hutton, Alan Johnston, Gonzalo Camarillo, Paul >>>> Kyzivat, Dave >>>> Smith, Parthasarathi, Dan Romascanu, Alissa Cooper, Charles Eckel >>>> >>>> Minutes produced by John Elwell. >>>> >>>> Webex chat: See end of these minutes. Jabber was not used. >>>> >>>> Recording day 1: >>>> https://workgreen.webex.com/workgreen/ldr.php?AT=pb&SP=MC&rID= >>>> 8263017&rK >>>> ey=19329980a044b45b >>>> >>>> Meeting started at 15.02. >>>> >>>> Topic - Administrivia (chairs) >>>> ============================== >>>> Slides: http://kenrehor.com/ietf/siprec/IETF79.2/Chairs.pdf >>>> >>>> No changes to published agenda. >>>> >>>> >>>> Topic - Requirements (Ken Rehor) >>>> draft-ietf-siprec-req-06 >>>> ================================ >>>> Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-req/ >>>> Slides: >>>> http://kenrehor.com/ietf/siprec/IETF79.2/IETF-79.2-SIPREC-Req- >>> 2011-01-25 >>>> .pdf >>>> >>>> Slide 4 - proposal to delete REQ-015/016. It was noted that these >>>> requirements talk about "cancel and discard". After some discussion, >>>> there seemed to be agreement that the "cancel" part was >>>> covered by other >>>> requirements (e.g., you can pause and not resume, effectively >>>> cancelling). So the main issue concerned the "discard" part. It was >>>> noted that previous agreements relating to privacy had reached the >>>> conclusion that the retention of recordings is an issue for >>>> the SRS, and >>>> outside the scope of SIPREC. There was no objection to >>>> deleting the two >>>> requirements. >>>> >>>> Although the main focus of the requirements is on what happens on > the >>>> SRC-SRS interface, Dave Smith brought up the question of whether a >>>> participant, whose SIP UA might not be collocated with the SRC, can >>>> request the pausing / stopping of a recording, or even >>>> request deletion >>>> of the recording. This would be a requirement impacting the CS, as >>>> opposed to the RS, and it was noted that none of the solution work > has >>>> touched on that (although the earlier draft from Alan >>>> Johnston did have >>>> provision for an indication on the CS signalling path that >>>> recording is >>>> taking place, but this was not brought forward into the >>>> present protocol >>>> draft). Dave was invited to raise on the list any fresh requirements >>>> concerning what CS participants might be able to request. >>>> >>>> Slide 5 - proposed new requirement on multiple media streams for the >>>> same media type. It was observed that REQ-010 was probably intended > to >>>> cover this case, and Ken will propose words to enhance REQ-010 to > make >>>> it clearer. >>>> >>>> Slide 6 - removal of REQ-021. There was no objection to removal. >>>> >>>> Ken will try to seek resolution of the issues above and then publish >>>> -07, which should be very close to being ready to submit to the > IESG. >>>> >>>> >>>> Topic - Metadata model (Ram Mohan) >>>> draft-ram-siprec-metadata-03 >>>> ================================================ >>>> Draft: https://datatracker.ietf.org/doc/draft-ram-siprec-metadata/ >>>> Slides: ???? >>>> >>>> Slide 4: Ram explained why an association between Media Stream and > CS >>>> had been introduced, because of the injection of things like music > on >>>> hold, leading to a media stream without participant. Charles > wondered >>>> why music on hold could not be considered a participant. Ram and > Paul >>>> explained there were also conference cases where a participant might >>>> host a conference on his device, but those behind the conferencing >>>> device might not be considered CS participants. Charles asked why > the >>>> conference focus could not be considered a participant. Paul > explained >>>> that the SRC could obtain, using the conference event >>>> package, a list of >>>> participants from the focus, and those participants would >>>> contribute to >>>> the media stream, but those participants would not be part of the CS > - >>>> that would be the role of the focus. Henry thought a mixer might be >>>> considered a participant, but Paul explained that if you can obtain > a >>>> roster of people behind the mixer, those might be considered >>>> participants rathe >>>> r than the mixer. So there can be participants in the media that are >>>> not participants in the CS. Charles was worried that some >>>> media streams >>>> might not have any identified participants who are generating the >>>> stream. Paul explained that, assuming the media from the > participants >>>> are mixed, you would see one media stream and a list of > participants. >>>> One participant might be joined to the CS and the others would not > be. >>>> Paul thinks we need to explore some use cases and see how >>>> they would be >>>> represented using this model. So if people have particular use > cases, >>>> make them known and we check how they would be represented. Ram will >>>> solicit use cases. Partha also had concerns similar to those >>>> of Charles, >>>> but Charles was beginning to see how the present model might >>>> work if you >>>> can get information about non-CS participants who are >>>> generating a media >>>> stream. Paul pointed out that the model does cater for a participant >>>> that is not part of a CS. Charles was invited to post his >>>> continued conc >>>> erns / scenarios to the list, but Paul thinks the use cases > concerned >>>> are already covered by the model. >>>> >>>> Slide 6 (CS Group): Nobody on list had come up with a reason >>>> for having >>>> more than one CSG associated with a single CS, and the conclusion >>>> reached on the list seems to stand. >>>> >>>> Slide 7 (CS): No comments on CS slide, except that forced >>>> deletion is to >>>> be removed in line with the requirements discussion. >>>> >>>> Slide 8 (Participant): Clarified that the multiple AORs are >>>> aliases, in >>>> the sense of P-Asserted-Identity being able to carry aliases. >>>> >>>> Concerning the issue of whether participant role is needed as an >>>> attribute, Leon suggested it could be done in application data, but >>>> asked whether we would then publish some application data > dictionary. >>>> Paul suggested that application data is just some additional >>>> XML in some >>>> other namespace, so some other group could get together and define > it. >>>> Leon was concerned that without some sort of standardization, >>>> different >>>> vendors would implement it differently. John suggested we >>>> need to decide >>>> what things are needed by 80% of deployments and standardize those > in >>>> this group, so if that is the case for participant role, we should >>>> standardize it. Partha wanted to include participant role, even > though >>>> there might be some cases where it is not available. Paul pointed > out >>>> that we had had considerable list discussion on the difficulties of >>>> figuring out the role: UAC/UAS is transaction specific, >>>> inbound/outbound >>>> is problematic, and incoming/outgoing, whilst it might work in some >>>> cases, it w >>>> ill not always work. Perhaps those focused on call centres >>>> can say what >>>> might/might not work. In conclusion, this has to be taken back to > the >>>> list. Without repeating the old arguments, those wanting to include >>>> participant role should indicate what are the likely mechanisms that >>>> might support it. >>>> >>>> Slide 10 (Media Stream): How to model media streams that are not >>>> recorded (rejected by SRS or no capability at SRS). Dave thought was >>>> important that you have some information in the metadata that >>>> there was >>>> media that was available for recording but couldn't be recorded, but >>>> there are two cases: where you don't want to record, or where >>>> because of >>>> a temporary limitation you are unable to record but might >>>> want to record >>>> later. Paul agreed, but was concerned about the details, although > that >>>> is very much down to the mechanism, e.g., does the SRC need to keep >>>> offering the stream? >>>> >>>> Partha asked a question on start time and end time. Ram clarified > this >>>> is these are start and end times of the CS media. It was pointed out >>>> that we have wall clock time in the metadata, and other times can be >>>> relative. Leon suggested there may be a need to retransmit wall > clock >>>> time occasionally, to compensate for drift. >>>> >>>> Henry asked whether media stream reference should be part of the >>>> mechanism rather than an attribute. >>>> >>>> Slide 10 (Application data): Leon agreed with the extensible > approach, >>>> based on different namespaces. Paul said that he would be tempted to >>>> stop calling it application data and call it extension data. >>>> John (from >>>> the floor) questioned whether it really is an object, or just >>>> attributes >>>> of other objects. Paul said it was just an artefact of how >>>> the model is >>>> drawn, but in the solution it would just be extensibility data. The >>>> authors will rework this with these comments in mind. >>>> >>>> On next steps, people are asked to review and submit further >>>> comments on >>>> -03, and -04 will be produced in due course, after which we might be >>>> consider adoption as a WG item. In particular, we need closure on > the >>>> long discussion of media stream relationships. >>>> >>>> >>>> Topic - Protocol (Henry Lum / Leon Portman) >>>> draft-portman-siprec-protocol-02 >>>> ================================================ >>>> Draft: > https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ >>>> Slides: > http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20- >>>> %20virtual%20interim%20Dec%2016%202010.pdf >>>> >>>> Slide 4 (Persistent recording): Leon pointed out that the >>>> whole idea of >>>> persistent recording is not to spend time negotiating m-lines >>>> when a CS >>>> starts - so he prefers the second option on the slide. For SRCs that >>>> support a large number of parallel CSs, the SRC could pre-negotiate > a >>>> large number of m-lines (perhaps based on licensing), rather like >>>> provisioning trunks. Paul felt that the other option should >>>> be kept open >>>> - a slight delay in negotiating a new m-line could be handled by >>>> transmitting the data slightly delayed, without losing any. Henry > also >>>> mentioned the possibility of the offer-answer failing. It was >>>> questioned >>>> whether there needs to be something in the protocol to indicate the >>>> delay. This issue should be brought to the list. >>>> >>>> >>>> Day 1 wrap-up >>>> ================================ >>>> >>>> It was agreed that on the second day we will start by completing the >>>> Protocol topic and then do the metadata format topic. >>>> >>>> The meeting was closed at 17.00. >>>> >>>> >>>> Day 1 chat log >>>> =============================== >>>> January 25, 2011 3:19:58 PM from Alissa Cooper >>>> to Everyone: I'm not in a place where I can speak in the audio, but > I >>>> think we decided not to have requirements related to what >>>> happens to the >>>> recording after it has been made. >>>> >>>> January 25, 2011 3:30:32 PM from Alissa Cooper >>>> to Everyone: it seems like there are cases where the hints are >>>> valuable even if they aren't always honoured >>>> >>>> January 25, 2011 3:39:51 PM from Alissa Cooper >>>> to Everyone: it's old, I'll take it to the list >>>> >>>> January 25, 2011 4:59:32 PM from Kenneth Rehor >>>> to Everyone: Unfortunately I have to drop off now. TTY tomorrow. >>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >>>> >>>> -------------------------------------------------------------- >>>> ----------------------------------------------------- >>>> CONFIDENTIALITY NOTICE: This e-mail and any files attached >>>> may contain confidential and proprietary information of >>>> Alcatel-Lucent and/or its affiliated entities. Access by the >>>> intended recipient only is authorized. Any liability arising >>>> from any party acting, or refraining from acting, on any >>>> information contained in this e-mail is hereby excluded. If >>>> you are not the intended recipient, please notify the sender >>>> immediately, destroy the original transmission and its >>>> attachments and do not disclose the contents to any other >>>> person, use it for any purpose, or store or copy the >>>> information in any medium. Copyright in this e-mail and any >>>> attachments belongs to Alcatel-Lucent and/or its affiliated > entities. >>>> >>>> >>> _______________________________________________ >>> 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 > > > ------------------------------------------------------------------------------------------------------------------- > CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities. > > From Dave.d.Smith@alcatel-lucent.com Mon Jan 31 21:10:44 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15DCF3A6B63 for ; Mon, 31 Jan 2011 21:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4XRQjp3mP9O for ; Mon, 31 Jan 2011 21:10:41 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 2A4603A6A2B for ; Mon, 31 Jan 2011 21:10:40 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p115DXRk011162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Jan 2011 23:13:33 -0600 (CST) Received: from relay-out2.dc (relay-out2.dc.genesyslab.com [172.22.68.188]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p115DV7o012647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 31 Jan 2011 23:13:33 -0600 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc (8.13.8+Sun/8.13.8) with ESMTP id p115DUec017668; Mon, 31 Jan 2011 21:13:30 -0800 (PST) Received: from SARUMAN.us.int.genesyslab.com ([192.168.20.90]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Jan 2011 21:13:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Jan 2011 21:13:27 -0800 Message-ID: In-Reply-To: <4D476F05.8060506@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Proposed change to REQ-017 concerning cancellation Thread-Index: AcvBt0PMa6ycGKc6QAOit07GFqVkOwAFxVOw References: <4D417365.60205@cisco.com> <4D476F05.8060506@cisco.com> From: "Dave Smith" To: "Paul Kyzivat" X-OriginalArrivalTime: 01 Feb 2011 05:13:30.0478 (UTC) FILETIME=[C3EE28E0:01CBC1CE] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: siprec@ietf.org Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 05:10:44 -0000 The user can have an indication that the recording isn't happening b/c of REQ-018: REQ-018 The mechanism MUST provide a means of indicating to the participants involved in a CS that their session is being recorded. For example, the indicator on the phone set/desktop or the "beep" indicator would go away. =20 Regards, Dave -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Monday, January 31, 2011 6:25 PM To: Dave Smith Cc: siprec@ietf.org; Alissa Cooper; Elwell, John Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation I agree that all of this *can* be done. My main question is whether any real user would believe it is *actually* being done? There really is no way to *verify* that the recording isn't=20= happening. But if this is thought to be useful it certainly can be done. Thanks, Paul On 1/31/2011 6:25 PM, Dave Smith wrote: > I agree that we do not need to consider Discarding the recording file > since Discarding is a policy matter, is about SRS functionality, and is > outside our scope. > However, I do think we should include functionality to support an > autonomous UA request to Stop recording (and BTW, probably even a UA > request to Start recording could be supported as well). > > As Alissa said, and I agree that REQ-001 to REQ-011 could be used to > Stop a recording. For example, in the Contact Center use case, if > developed appropriately, a Customer could verbally ask an Agent to stop > the recording and the Agent could then send a signal to the SRC to Stop > recording. And probably similar functionality could be done by an IVR > (e.g., "Select 3 to terminate recording"). However, I believe this > could/should be done more elegantly by allowing a UA to request to Stop > recording autonomously. > > If you disagree, then it makes no sense to keep REQ-017 at all. > If REQ-017 is going to be kept, then it should include "during" as well > as "prior to the start of recording." > > Regards, > Dave > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Thursday, January 27, 2011 5:30 AM > To: siprec@ietf.org > Subject: Re: [siprec] Proposed change to REQ-017 concerning cancellation > > Inline > > On 1/27/2011 8:02 AM, Alissa Cooper wrote: >> As written, I think this use case (and the revised REQ-017) is still >> slightly ambiguous. There seem to be three cases: >> >> (1) Recording starts. Customer requests that recording be stopped. >> Recording stops. >> (2) Recording starts. Customer requests that recording be stopped and >> discarded. Recording stops. Recording is discarded. >> (3) Recording starts. Customer requests that recording be stopped and >> discarded. Recording stops but recording is not discarded. >> >> I think (1) is already covered between REQ-001 and REQ-011. >> >> I think (2) is by and large what we were discussing when we were > talking >> about ditching REQ-015 and REQ-016. As noted during the virtual > interim >> day 1, whether the SRS actually discards the recording depends on > policy >> set by the SRC, which we had said was out of scope. >> >> BUT it sort of sounded like case (3) might be of interest -- i.e., > that >> having the ability for an SRC to send an indication to the SRS of the >> customer's preference that the recording be discarded, even if that >> preference will not always be honored, is something that we may want > to >> support. If that's the case, it might merit its own requirement ("The >> mechanism MUST provide a means for an SRC to indicate to an SRS a >> preference to discard a recording" or something like that). > > There is a fundamental difference between 1 and 2/3. > > The customer (I assume this to be a participant not in control of the > SRC) can *ask* that the recording be discarded. But he can not be > certain that is has been. > > Similarly, the agent (or any participant that *is* in control of the > SRC) could (if we provide a suitable mechanism) *ask* the SRS to discard > > the recording. But again he cannot be certain it has been. > > We could even provide a mechanism to ACK/NACK a request to discard a > recording. That could allow the SRC a bit more knowledge, but the SRS > could still by lying. > > Only the SRS *knows* if the recording has been discarded. Whether it > does so when asked will depend upon its operating policies, which could > include policies that violate the law. > > So, given all of that, is it worth the trouble to include a mechanism to > > request the discard of a recording, and to ACK/NACK that request??? > > If that is felt to be important, then it will be a bit of work, because > we will need to define *what* is to be discarded, and that is > non-trivial. > > I mentioned on the list the mechanism that exists in some email systems > to "retract" an email. AFAIK this very rarely "works" - it often results > > in all the recipients getting another email saying "John Smith would > like to recall email xyz", but *does not* result in the intended result. > > I think requesting that a recording be discarded falls into he same > category. If you seriously want to ensure that a recording has been > discarded, then I suggest you hire a lawyer and file a lawsuit. > > Thanks, > Paul > >> Alissa >> >> On Jan 27, 2011, at 7:03 AM, Elwell, John wrote: >> >>> Just changed the subject line so that people concerned will notice > it. >>> >>> John >>> >>>> -----Original Message----- >>>> From: Dave Smith [mailto:Dave.d.Smith@alcatel-lucent.com] >>>> Sent: 26 January 2011 21:22 >>>> To: Elwell, John; siprec@ietf.org >>>> Subject: RE: [siprec] Minutes day 1 >>>> >>>> Hi, >>>> Here is my input to my Action Item related to REQ-015/016 - >>>> to raise on >>>> the list any fresh requirements concerning what CS >>>> participants might be >>>> able to request regarding "canceling" and/or "discarding" recording. >>>> >>>> It seems that REQ-017 already covers the basic idea; however, >>>> REQ-017 is >>>> only valid " prior to the start of recording ". My concern >>>> was for the >>>> mechanism to also work "during" recording. >>>> Therefore, my proposal is to consider to update REQ-017 as follows: >>>> >>>> Currently it reads: >>>> o REQ-017 The mechanism MUST support a means for an authorized >>>> participant involved in a CS to request, prior to the start of >>>> recording, that the CS not be recorded >>>> >>>> Change to: >>>> o REQ-017 The mechanism MUST support a means for an authorized >>>> participant involved in a CS to request, during or prior >>>> to the start >>>> of >>>> recording, that the CS not be recorded >>>> >>>> >>>> Use Case supporting this change: >>>> 1. Customer calls a contact center >>>> 2. Agent answers the phone >>>> 3. Customer starts discussing their issue with the Agent >>>> 4. Customer realizes that the call is being recorded (e.g., >>>> they hear a "beep" tone indicating that the call is currently being >>>> recorded) >>>> 5. Customer decides that they do not want the call to be >>>> recorded >>>> 6. Customer requests that the call not be recorded (e.g., >>>> customer phone application is used to send a signal within the CS > that >>>> can be received/interpreted by the SRC) >>>> 7. The SRC stops the recording >>>> Also note the following that could further be done, if an >>>> implementation >>>> desires (no req'ts needed): >>>> Optional: 8. The SRC sends metadata to the SRS indicating that >>>> the Customer requested that the call NOT be recorded >>>> Optional: 9. The SRS uses its internal policy procedures and >>>> decides to delete the recorded audio file from the Customer > recording >>>> >>>> >>>> >>>> Let me know your inputs and if this change makes sense. >>>> >>>> >>>> Regards, >>>> Dave >>>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] On Behalf >>>> Of Elwell, John >>>> Sent: Tuesday, January 25, 2011 2:24 PM >>>> To: siprec@ietf.org >>>> Subject: [siprec] Minutes day 1 >>>> >>>> Minutes of the SIPREC WG Interim Virtual Meeting >>>> 2011-01-25, 15.00-17.00 GMT/UTC and >>>> 2011-01-25, 14.00-16.00 GMT/UTC >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> Meeting chaired by Brian Rosen and John Elwell. >>>> >>>> Participants (session 1): Brian Rosen, John Elwell, Ken Rehor, Leon >>>> Portman, Henry Lum, Ram >>>> Mohen, Andy Hutton, Alan Johnston, Gonzalo Camarillo, Paul >>>> Kyzivat, Dave >>>> Smith, Parthasarathi, Dan Romascanu, Alissa Cooper, Charles Eckel >>>> >>>> Minutes produced by John Elwell. >>>> >>>> Webex chat: See end of these minutes. Jabber was not used. >>>> >>>> Recording day 1: >>>> https://workgreen.webex.com/workgreen/ldr.php?AT=3Dpb&SP=3DMC&rID=3D= >>>> 8263017&rK >>>> ey=3D19329980a044b45b >>>> >>>> Meeting started at 15.02. >>>> >>>> Topic - Administrivia (chairs) >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >>>> Slides: http://kenrehor.com/ietf/siprec/IETF79.2/Chairs.pdf >>>> >>>> No changes to published agenda. >>>> >>>> >>>> Topic - Requirements (Ken Rehor) >>>> draft-ietf-siprec-req-06 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-req/ >>>> Slides: >>>> http://kenrehor.com/ietf/siprec/IETF79.2/IETF-79.2-SIPREC-Req- >>> 2011-01-25 >>>> .pdf >>>> >>>> Slide 4 - proposal to delete REQ-015/016. It was noted that these >>>> requirements talk about "cancel and discard". After some discussion, >>>> there seemed to be agreement that the "cancel" part was >>>> covered by other >>>> requirements (e.g., you can pause and not resume, effectively >>>> cancelling). So the main issue concerned the "discard" part. It was >>>> noted that previous agreements relating to privacy had reached the >>>> conclusion that the retention of recordings is an issue for >>>> the SRS, and >>>> outside the scope of SIPREC. There was no objection to >>>> deleting the two >>>> requirements. >>>> >>>> Although the main focus of the requirements is on what happens on > the >>>> SRC-SRS interface, Dave Smith brought up the question of whether a >>>> participant, whose SIP UA might not be collocated with the SRC, can >>>> request the pausing / stopping of a recording, or even >>>> request deletion >>>> of the recording. This would be a requirement impacting the CS, as >>>> opposed to the RS, and it was noted that none of the solution work > has >>>> touched on that (although the earlier draft from Alan >>>> Johnston did have >>>> provision for an indication on the CS signalling path that >>>> recording is >>>> taking place, but this was not brought forward into the >>>> present protocol >>>> draft). Dave was invited to raise on the list any fresh requirements >>>> concerning what CS participants might be able to request. >>>> >>>> Slide 5 - proposed new requirement on multiple media streams for the >>>> same media type. It was observed that REQ-010 was probably intended > to >>>> cover this case, and Ken will propose words to enhance REQ-010 to > make >>>> it clearer. >>>> >>>> Slide 6 - removal of REQ-021. There was no objection to removal. >>>> >>>> Ken will try to seek resolution of the issues above and then publish >>>> -07, which should be very close to being ready to submit to the > IESG. >>>> >>>> >>>> Topic - Metadata model (Ram Mohan) >>>> draft-ram-siprec-metadata-03 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >>>> Draft: https://datatracker.ietf.org/doc/draft-ram-siprec-metadata/ >>>> Slides: ???? >>>> >>>> Slide 4: Ram explained why an association between Media Stream and > CS >>>> had been introduced, because of the injection of things like music > on >>>> hold, leading to a media stream without participant. Charles > wondered >>>> why music on hold could not be considered a participant. Ram and > Paul >>>> explained there were also conference cases where a participant might >>>> host a conference on his device, but those behind the conferencing >>>> device might not be considered CS participants. Charles asked why > the >>>> conference focus could not be considered a participant. Paul > explained >>>> that the SRC could obtain, using the conference event >>>> package, a list of >>>> participants from the focus, and those participants would >>>> contribute to >>>> the media stream, but those participants would not be part of the CS > - >>>> that would be the role of the focus. Henry thought a mixer might be >>>> considered a participant, but Paul explained that if you can obtain > a >>>> roster of people behind the mixer, those might be considered >>>> participants rathe >>>> r than the mixer. So there can be participants in the media that are >>>> not participants in the CS. Charles was worried that some >>>> media streams >>>> might not have any identified participants who are generating the >>>> stream. Paul explained that, assuming the media from the > participants >>>> are mixed, you would see one media stream and a list of > participants. >>>> One participant might be joined to the CS and the others would not > be. >>>> Paul thinks we need to explore some use cases and see how >>>> they would be >>>> represented using this model. So if people have particular use > cases, >>>> make them known and we check how they would be represented. Ram will >>>> solicit use cases. Partha also had concerns similar to those >>>> of Charles, >>>> but Charles was beginning to see how the present model might >>>> work if you >>>> can get information about non-CS participants who are >>>> generating a media >>>> stream. Paul pointed out that the model does cater for a participant >>>> that is not part of a CS. Charles was invited to post his >>>> continued conc >>>> erns / scenarios to the list, but Paul thinks the use cases > concerned >>>> are already covered by the model. >>>> >>>> Slide 6 (CS Group): Nobody on list had come up with a reason >>>> for having >>>> more than one CSG associated with a single CS, and the conclusion >>>> reached on the list seems to stand. >>>> >>>> Slide 7 (CS): No comments on CS slide, except that forced >>>> deletion is to >>>> be removed in line with the requirements discussion. >>>> >>>> Slide 8 (Participant): Clarified that the multiple AORs are >>>> aliases, in >>>> the sense of P-Asserted-Identity being able to carry aliases. >>>> >>>> Concerning the issue of whether participant role is needed as an >>>> attribute, Leon suggested it could be done in application data, but >>>> asked whether we would then publish some application data > dictionary. >>>> Paul suggested that application data is just some additional >>>> XML in some >>>> other namespace, so some other group could get together and define > it. >>>> Leon was concerned that without some sort of standardization, >>>> different >>>> vendors would implement it differently. John suggested we >>>> need to decide >>>> what things are needed by 80% of deployments and standardize those > in >>>> this group, so if that is the case for participant role, we should >>>> standardize it. Partha wanted to include participant role, even > though >>>> there might be some cases where it is not available. Paul pointed > out >>>> that we had had considerable list discussion on the difficulties of >>>> figuring out the role: UAC/UAS is transaction specific, >>>> inbound/outbound >>>> is problematic, and incoming/outgoing, whilst it might work in some >>>> cases, it w >>>> ill not always work. Perhaps those focused on call centres >>>> can say what >>>> might/might not work. In conclusion, this has to be taken back to > the >>>> list. Without repeating the old arguments, those wanting to include >>>> participant role should indicate what are the likely mechanisms that >>>> might support it. >>>> >>>> Slide 10 (Media Stream): How to model media streams that are not >>>> recorded (rejected by SRS or no capability at SRS). Dave thought was >>>> important that you have some information in the metadata that >>>> there was >>>> media that was available for recording but couldn't be recorded, but >>>> there are two cases: where you don't want to record, or where >>>> because of >>>> a temporary limitation you are unable to record but might >>>> want to record >>>> later. Paul agreed, but was concerned about the details, although > that >>>> is very much down to the mechanism, e.g., does the SRC need to keep >>>> offering the stream? >>>> >>>> Partha asked a question on start time and end time. Ram clarified > this >>>> is these are start and end times of the CS media. It was pointed out >>>> that we have wall clock time in the metadata, and other times can be >>>> relative. Leon suggested there may be a need to retransmit wall > clock >>>> time occasionally, to compensate for drift. >>>> >>>> Henry asked whether media stream reference should be part of the >>>> mechanism rather than an attribute. >>>> >>>> Slide 10 (Application data): Leon agreed with the extensible > approach, >>>> based on different namespaces. Paul said that he would be tempted to >>>> stop calling it application data and call it extension data. >>>> John (from >>>> the floor) questioned whether it really is an object, or just >>>> attributes >>>> of other objects. Paul said it was just an artefact of how >>>> the model is >>>> drawn, but in the solution it would just be extensibility data. The >>>> authors will rework this with these comments in mind. >>>> >>>> On next steps, people are asked to review and submit further >>>> comments on >>>> -03, and -04 will be produced in due course, after which we might be >>>> consider adoption as a WG item. In particular, we need closure on > the >>>> long discussion of media stream relationships. >>>> >>>> >>>> Topic - Protocol (Henry Lum / Leon Portman) >>>> draft-portman-siprec-protocol-02 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >>>> Draft: > https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ >>>> Slides: > http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20- >>>> %20virtual%20interim%20Dec%2016%202010.pdf >>>> >>>> Slide 4 (Persistent recording): Leon pointed out that the >>>> whole idea of >>>> persistent recording is not to spend time negotiating m-lines >>>> when a CS >>>> starts - so he prefers the second option on the slide. For SRCs that >>>> support a large number of parallel CSs, the SRC could pre-negotiate > a >>>> large number of m-lines (perhaps based on licensing), rather like >>>> provisioning trunks. Paul felt that the other option should >>>> be kept open >>>> - a slight delay in negotiating a new m-line could be handled by >>>> transmitting the data slightly delayed, without losing any. Henry > also >>>> mentioned the possibility of the offer-answer failing. It was >>>> questioned >>>> whether there needs to be something in the protocol to indicate the >>>> delay. This issue should be brought to the list. >>>> >>>> >>>> Day 1 wrap-up >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> >>>> It was agreed that on the second day we will start by completing the >>>> Protocol topic and then do the metadata format topic. >>>> >>>> The meeting was closed at 17.00. >>>> >>>> >>>> Day 1 chat log >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >>>> January 25, 2011 3:19:58 PM from Alissa Cooper >>>> to Everyone: I'm not in a place where I can speak in the audio, but > I >>>> think we decided not to have requirements related to what >>>> happens to the >>>> recording after it has been made. >>>> >>>> January 25, 2011 3:30:32 PM from Alissa Cooper >>>> to Everyone: it seems like there are cases where the hints are >>>> valuable even if they aren't always honoured >>>> >>>> January 25, 2011 3:39:51 PM from Alissa Cooper >>>> to Everyone: it's old, I'll take it to the list >>>> >>>> January 25, 2011 4:59:32 PM from Kenneth Rehor >>>> to Everyone: Unfortunately I have to drop off now. TTY tomorrow. >>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >>>> >>>> -------------------------------------------------------------- >>>> ----------------------------------------------------- >>>> CONFIDENTIALITY NOTICE: This e-mail and any files attached >>>> may contain confidential and proprietary information of >>>> Alcatel-Lucent and/or its affiliated entities. Access by the >>>> intended recipient only is authorized. Any liability arising >>>> from any party acting, or refraining from acting, on any >>>> information contained in this e-mail is hereby excluded. If >>>> you are not the intended recipient, please notify the sender >>>> immediately, destroy the original transmission and its >>>> attachments and do not disclose the contents to any other >>>> person, use it for any purpose, or store or copy the >>>> information in any medium. Copyright in this e-mail and any >>>> attachments belongs to Alcatel-Lucent and/or its affiliated > entities. >>>> >>>> >>> _______________________________________________ >>> 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 > > =09 > ------------------------------------------------------------------------ ------------------------------------------- > CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities. > =09 > =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From john.elwell@siemens-enterprise.com Mon Jan 31 23:25:39 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCC1F3A6B05 for ; Mon, 31 Jan 2011 23:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.237 X-Spam-Level: X-Spam-Status: No, score=-102.237 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0Ge+mcCWjhp for ; Mon, 31 Jan 2011 23:25:38 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 5DE0F3A6AF0 for ; Mon, 31 Jan 2011 23:25:38 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3221092; Tue, 1 Feb 2011 08:28:53 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 164CB23F0278; Tue, 1 Feb 2011 08:28:53 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 1 Feb 2011 08:28:53 +0100 From: "Elwell, John" To: Paul Kyzivat , "siprec@ietf.org" Date: Tue, 1 Feb 2011 08:28:51 +0100 Thread-Topic: [siprec] mechansim for requesting no-record for recording aware UA Thread-Index: AcvBtrvY+4K6dol3SeWfmBSZbyPs/QAKEftw Message-ID: References: <059AF07365DC474393A19A3AF187DF7406A1EE1B@NAHALD.us.int.genesyslab.com> <4D476E23.5060104@cisco.com> In-Reply-To: <4D476E23.5060104@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] mechansim for requesting no-record for recording aware UA X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 07:25:39 -0000 1. One thing we need to clarify is which entity has the final say on whethe= r recording will take place - the SRC or the SRS. In the SRC case, if no-re= cord is requested, the SRC would not offer the session or medium to the SRS= . In the SRS case, the SRC would pass the no-record request to the SRS, whi= ch would respond according to its policy. Although superficially this does = not impact the choice of mechanism on the CS, the time taken to consult the= SRS might possibly have some influence. For example, it might not be possi= ble to signal the outcome in the response to the CS request that asked for = no-record (c.f., discussions taking place in SIPCORE on whether, for a no-I= NVITE transaction, you can expect to dereference the location URL before se= nding the SIP response). This might be an issue for some of the proposed me= chanisms for no-record. 2. Either UA in the call might request no-record, and at any stage in the c= all, so we cannot assume the request will be in in the initial INVITE reque= st. If the callee UA wants to request no-record, it could do it in response= to the initial INVITE request, or in a separate request. If it is in a res= ponse, we would need to use another request, in the reverse direction, to s= ignal the outcome. Mechanisms such as caller preferences and the Require he= ader field would not work for a response. Asking for no-record in a mid-dia= log request might also have issues - I am not sure how caller preferences w= ould apply, and use of the Require header field would perhaps not have the = desired outcome. Finally, whatever mechanism we choose must be usable in 3P= CC situations. 3. Do we need a mechanism whereby the CS is automatically cleared if no-rec= ord cannot be granted, or is it sufficient just to indicate this to the use= r concerned and leave the user to take action? Certainly if we decide that = no-record can be on a per-medium basis, automatically clearing the call see= ms unreasonable. John (as individual) > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 01 February 2011 02:21 > To: siprec@ietf.org > Subject: Re: [siprec] mechansim for requesting no-record for=20 > recording aware UA >=20 > Just to be clear, this is discussing how this request is indicated in=20 > the *CS*, right? >=20 > I *think* I prefer option 3 (in SDP) for the flexibility it gives and=20 > because fundamentally this is about media. However that=20 > probably won't=20 > say anything about whether *metadata* about the call is=20 > recorded. Do we=20 > care about that? >=20 > Thanks, > Paul >=20 > On 1/31/2011 5:16 PM, Henry Lum wrote: > > This is one of the issues from the interim call. > > > > In order for a recording-aware UA to request that a call not to be > > recorded, there are 3 proposed mechanisms. I want to get feedback on > > which mechanism is most appropriate to meet REQ-017 and REQ-018: > > > > 1)Use caller preference to request that a call not to be recorded > > > > For example, > > > > Reject-Contact: *;sip.recorded > > > > For a UA to request that a call not to be recorded. When the call is > > being recorded, use the feature tag sip.recorded to=20 > indicate that the > > call is being recorded. The mechanism is optional so this=20 > preference may > > not be honored all the time. Also, the mechanism in=20 > Reject-Contact would > > prevent the call from connecting there are no contacts that=20 > would not > > record the call. > > > > 2)Specify a new SIP header to indicate recording preference > > > > Define a new option tag called no-record and use a new SIP header to > > indicate recording preference in a new SIP header. > > > > For example, > > > > Record-Preference: record / no-record-reject / no-record-accept > > > > record means that the caller is requesting the call to be recorded > > > > no-record-reject means that the caller does not wish to=20 > connect the call > > if the call must be recorded. > > > > no-record-accept means that the caller does not wish to be=20 > recorded but > > may establish the call is recording is enabled. > > > > When the call is recorded, use the feature tag sip.recorded=20 > to indicate > > that the call is being recorded. > > > > 3)Define a new SDP attribute to request for either a=20 > session or media > > stream not to be recorded. > > > > This one is suggested during the interim call and allows=20 > the caller to > > indicate recording preference using a session-level or media-level > > attribute. We can define two attributes: > > > > a=3Drecordpref:[preference] > > > > preference =3D "record" / "no-record-reject" / "no-record-accept" > > > > The meaning of the preferences are the same as 2) above. > > > > a=3Drecord:[state] > > > > state =3D "active" / "inactive" > > > > The first attribute is used by the user agent who wishes to=20 > indicate the > > preference for recording the session. The second attribute=20 > is used to > > indicate whether recording is actually active or inactive. This > > mechanism also allows a user agent is allowed to send a=20 > reINVITE in the > > middle of the call to change the recording preference. > > > > Regards, > > > > Henry > > > > > > > > CONFIDENTIALITY NOTICE: This e-mail and any files attached=20 > may contain > > confidential and proprietary information of Alcatel-Lucent=20 > and/or its > > affiliated entities. Access by the intended recipient only is > > authorized. Any liability arising from any party acting, or=20 > refraining > > from acting, on any information contained in this e-mail is hereby > > excluded. If you are not the intended recipient, please notify the > > sender immediately, destroy the original transmission and its > > attachments and do not disclose the contents to any other=20 > person, use it > > for any purpose, or store or copy the information in any medium. > > Copyright in this e-mail and any attachments belongs to=20 > Alcatel-Lucent > > and/or its affiliated entities. > > > > > > > > _______________________________________________ > > 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 > =