From nobody Tue Apr 1 11:23:25 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B83C1A088C for ; Tue, 1 Apr 2014 11:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ex2elTMyqBOK for ; Tue, 1 Apr 2014 11:23:19 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id CE2A51A0505 for ; Tue, 1 Apr 2014 11:23:19 -0700 (PDT) Received: from userPC (unknown [122.167.104.66]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 308AB15C80F0; Tue, 1 Apr 2014 18:23:10 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1396376596; bh=5PvTlJBj/3BGeN9DH/wDeU/6PwPaMpRcOnPCwDHKxkw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ho1Z6zqtCRyaq40XBM0p4b8SuUJc8Lh/z1ofPAec5dXMYvsZU1gYDqNHp89RGkg2C VOvnfZ3VDvOrIgWvNPmx6kZaadgUmat+wvNbiVtZNcA5N4va1PYb8l3/A2Ffb9x8zX 0QJhNLk/Prjw3zd/y0n9QvSkIZ0+Y5EsYShd1b7U= From: "Parthasarathi R" To: "'Ram Mohan R \(rmohanr\)'" , , References: <001c01cf3cc1$7b0ce0f0$7126a2d0$@co.in> <67DAF295CD01EB44AE6EA8A51F6ABF0A43559C0758@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: Date: Tue, 1 Apr 2014 23:53:05 +0530 Message-ID: <002e01cf4dd7$70a76640$51f632c0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPPR/RGuM4Kd8dwUawEqFUPJjgfJr9M5hA Content-Language: en-us X-CTCH-RefID: str=0001.0A020202.533B0414.000E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.93 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/4OS-KwawZZcr26R8Tnt4Zj31ro8 Cc: siprec@ietf.org Subject: Re: [siprec] SIPREC metadata example comments X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2014 18:23:22 -0000 Hi Finlay/Gerben, Hope the below reply addresses your concern.=20 Also, I'm interested in knowing whether you have any other issues = related to SIPREC metadata which has to be discussed before WGLC of the draft. Thanks Partha > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: Tuesday, March 11, 2014 5:18 PM > To: finlay.fraser@bt.com; partha@parthasarathi.co.in; > Gerben.Stam@nice.com > Cc: siprec@ietf.org > Subject: Re: [siprec] SIPREC metadata example comments >=20 > Please see inline for some comments >=20 > -----Original Message----- > From: "finlay.fraser@bt.com" > Date: Tuesday, 11 March 2014 1:59 pm > To: "partha@parthasarathi.co.in" , > "Gerben.Stam@nice.com" > Cc: "siprec@ietf.org" > Subject: Re: [siprec] SIPREC metadata example comments >=20 > >Partha > > > >Are you saying RFC4575 is mandatory package for SIPREC support and > would > >have to be available. >=20 > No. SIPREC does not mandate you to have RFC4575. It is up to the SRC > (participant in the conference in this example) to learn the details = of > the other participant in the conference session before it sends > snapshot > of metadata to SRS. It may use RFC4575 method by subscribing to a > conference focus or use some other means to get the details. We are = not > mandating to use RFC4575 only. >=20 > SIPREC only talks about how a SRC sends(the protocol semantics) > metadata > to SRS and semantics of metadata(XML schema). How SRC gets the > information > that fills up metadata is purely a application logic and IMO need not > be > defined in the on-wire protocol. >=20 > > > >If not and there is no RFC4575 feed available how does the = participant > >know about all the other parties and their state if they are not sent > in > >the Metadata UPDATE > > > >Or have I missed the meaning of the paragraph > > > >On the use of groups in trading > > > >We have a use case where two communication sessions that are > established > >with one or more parties merge together to form a single call. We = need > a > >way to tag all legs of the call to indicate this. To do this we > propose > >to use Group so the two CS will stay the same but both will now share > a > >group tag. >=20 > Yes. CS-group is specifically is meant for this purpose. If a > application > wants to link two CS=B9s it can use this CS-group and tag them = together. > Your understanding is correct here. >=20 > Regards, > Ram >=20 > > > >Note it is also possible for merge calls to be merged. When this > happens > >a new group tag will be added. > >In this way a VR can find original CS and be aware that it was merged > and > >from the merge tags it can locate all other parties in the call. > > > >If there is a better way to deal with this pleases let me know. > > > > > >Finlay Fraser > >Annandale House > >1 Hanworth Road > >Sunbury on Thames > >TW16 5DJ > >BT IP Tel: +44 (0)1932773310 | Mob: +44(0)7711860228 | E: > >finlay.fraser@bt.com > >________________________________________ > >From: siprec [siprec-bounces@ietf.org] On Behalf Of Parthasarathi R > >[partha@parthasarathi.co.in] > >Sent: 11 March 2014 00:33 > >To: Gerben.Stam@nice.com > >Cc: siprec@ietf.org > >Subject: [siprec] SIPREC metadata example comments > > > >Hi Gerben, > > > >In IETF-89 SIPREC meeting, you have mentioned about two issues = related > to > >SIRPEC metadata > > > >1) Trading scenario wherein the participant added/removed very = quickly > as > >it > >is conference. Here the concern is that all participant are required > to be > >forwarded SRC to SRS whenever there is a change in participants. > > > > Sec 3.3.3 of > >http://tools.ietf.org/html/draft-ietf-siprec-callflows-02#page-24 > explains > >how to add/remove participant without sending every participant. > Please > >let > >me know in case you have any difficulties in using this solution. > > > > > >2) Group is interpreted differently in trading scenario. > > > >Please look into Sec 3.5 of > >http://tools.ietf.org/html/draft-ietf-siprec-callflows-02#page-28 as > it > >is a > >trading scenario to understand the one of the possible usage with > group. > >Having said that, I'm not very clear about your problem statement. > Please > >clarify in case I didn't understand your concern. > > > >Thanks > >Partha > > > >_______________________________________________ > >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 nobody Wed Apr 2 02:15:03 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035DE1A0178 for ; Wed, 2 Apr 2014 02:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4W46e8n14EHA for ; Wed, 2 Apr 2014 02:14:58 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id AE9A51A0183 for ; Wed, 2 Apr 2014 02:14:55 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.169.1; Wed, 2 Apr 2014 10:15:00 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.212]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Wed, 2 Apr 2014 10:14:22 +0100 From: To: , , Date: Wed, 2 Apr 2014 10:10:02 +0100 Thread-Topic: [siprec] SIPREC metadata example comments Thread-Index: AQHPPR/RGuM4Kd8dwUawEqFUPJjgfJr9M5hAgAD40Ik= Message-ID: <67DAF295CD01EB44AE6EA8A51F6ABF0A4357640940@EMV62-UKRD.domain1.systemhost.net> References: <001c01cf3cc1$7b0ce0f0$7126a2d0$@co.in> <67DAF295CD01EB44AE6EA8A51F6ABF0A43559C0758@EMV62-UKRD.domain1.systemhost.net> ,<002e01cf4dd7$70a76640$51f632c0$@co.in> In-Reply-To: <002e01cf4dd7$70a76640$51f632c0$@co.in> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/v7xPkVvHk9jatg0cxLTH9fG9X28 Cc: siprec@ietf.org Subject: Re: [siprec] SIPREC metadata example comments X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2014 09:15:03 -0000 Thanks for getting back to us=20 On the groups we are happy that this is a correct use. On the conference you are saying this is an application level problem=20 Just as a bit of background we have decided to only report first party conn= ections and disconnections to CS's in an RS. So only connections by entitie= s recorded in this RS. This has allowed us to reduced the exponential incre= ase in traffic caused by reporting all connection changes for all users in = a large conference to every RS involved. Finlay Fraser Annandale House 1 Hanworth Road Sunbury on Thames TW16 5DJ BT IP Tel: +44 (0)1932773310 | Mob: +44(0)7711860228 | E: finlay.fraser@bt.= com ________________________________________ From: Parthasarathi R [partha@parthasarathi.co.in] Sent: 01 April 2014 19:23 To: 'Ram Mohan R (rmohanr)'; Fraser,FJ,Finlay,JRM13 R; Gerben.Stam@nice.com Cc: siprec@ietf.org Subject: RE: [siprec] SIPREC metadata example comments Hi Finlay/Gerben, Hope the below reply addresses your concern. Also, I'm interested in knowing whether you have any other issues related t= o SIPREC metadata which has to be discussed before WGLC of the draft. Thanks Partha > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: Tuesday, March 11, 2014 5:18 PM > To: finlay.fraser@bt.com; partha@parthasarathi.co.in; > Gerben.Stam@nice.com > Cc: siprec@ietf.org > Subject: Re: [siprec] SIPREC metadata example comments > > Please see inline for some comments > > -----Original Message----- > From: "finlay.fraser@bt.com" > Date: Tuesday, 11 March 2014 1:59 pm > To: "partha@parthasarathi.co.in" , > "Gerben.Stam@nice.com" > Cc: "siprec@ietf.org" > Subject: Re: [siprec] SIPREC metadata example comments > > >Partha > > > >Are you saying RFC4575 is mandatory package for SIPREC support and > would > >have to be available. > > No. SIPREC does not mandate you to have RFC4575. It is up to the SRC > (participant in the conference in this example) to learn the details of > the other participant in the conference session before it sends > snapshot > of metadata to SRS. It may use RFC4575 method by subscribing to a > conference focus or use some other means to get the details. We are not > mandating to use RFC4575 only. > > SIPREC only talks about how a SRC sends(the protocol semantics) > metadata > to SRS and semantics of metadata(XML schema). How SRC gets the > information > that fills up metadata is purely a application logic and IMO need not > be > defined in the on-wire protocol. > > > > >If not and there is no RFC4575 feed available how does the participant > >know about all the other parties and their state if they are not sent > in > >the Metadata UPDATE > > > >Or have I missed the meaning of the paragraph > > > >On the use of groups in trading > > > >We have a use case where two communication sessions that are > established > >with one or more parties merge together to form a single call. We need > a > >way to tag all legs of the call to indicate this. To do this we > propose > >to use Group so the two CS will stay the same but both will now share > a > >group tag. > > Yes. CS-group is specifically is meant for this purpose. If a > application > wants to link two CS=B9s it can use this CS-group and tag them together. > Your understanding is correct here. > > Regards, > Ram > > > > >Note it is also possible for merge calls to be merged. When this > happens > >a new group tag will be added. > >In this way a VR can find original CS and be aware that it was merged > and > >from the merge tags it can locate all other parties in the call. > > > >If there is a better way to deal with this pleases let me know. > > > > > >Finlay Fraser > >Annandale House > >1 Hanworth Road > >Sunbury on Thames > >TW16 5DJ > >BT IP Tel: +44 (0)1932773310 | Mob: +44(0)7711860228 | E: > >finlay.fraser@bt.com > >________________________________________ > >From: siprec [siprec-bounces@ietf.org] On Behalf Of Parthasarathi R > >[partha@parthasarathi.co.in] > >Sent: 11 March 2014 00:33 > >To: Gerben.Stam@nice.com > >Cc: siprec@ietf.org > >Subject: [siprec] SIPREC metadata example comments > > > >Hi Gerben, > > > >In IETF-89 SIPREC meeting, you have mentioned about two issues related > to > >SIRPEC metadata > > > >1) Trading scenario wherein the participant added/removed very quickly > as > >it > >is conference. Here the concern is that all participant are required > to be > >forwarded SRC to SRS whenever there is a change in participants. > > > > Sec 3.3.3 of > >http://tools.ietf.org/html/draft-ietf-siprec-callflows-02#page-24 > explains > >how to add/remove participant without sending every participant. > Please > >let > >me know in case you have any difficulties in using this solution. > > > > > >2) Group is interpreted differently in trading scenario. > > > >Please look into Sec 3.5 of > >http://tools.ietf.org/html/draft-ietf-siprec-callflows-02#page-28 as > it > >is a > >trading scenario to understand the one of the possible usage with > group. > >Having said that, I'm not very clear about your problem statement. > Please > >clarify in case I didn't understand your concern. > > > >Thanks > >Partha > > > >_______________________________________________ > >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 nobody Mon Apr 7 05:59:58 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEEF1A0702 for ; Mon, 7 Apr 2014 05:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Y-OKy2buPWb for ; Mon, 7 Apr 2014 05:59:51 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 7A04A1A06FB for ; Mon, 7 Apr 2014 05:59:51 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id B453A23F053E for ; Mon, 7 Apr 2014 14:59:44 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.60]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0174.001; Mon, 7 Apr 2014 14:59:44 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: Confirming Consensus on SIPREC Charter Update. Thread-Index: AQHPBh2Hk9hG1GEB8kaXnfAFAr7O5ZpxiHGAgJDCJoA= Date: Mon, 7 Apr 2014 12:59:43 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17D69BCD@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF17C8D262@MCHP04MSX.global-ad.net> <52C58B5F.6040400@alum.mit.edu> In-Reply-To: <52C58B5F.6040400@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/0IKu56Da9RB85qvVQB0iYDiGlxA Subject: [siprec] Confirming Consensus on SIPREC Charter Update. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 07 Apr 2014 12:59:56 -0000 Hi All, During the discussion at IETF89 it was pointed out that in clarifying the s= cope of SIPREC we should have mentioned real-time text so I have added RTT = to the list of media within scope in the proposed update to the charter. Following this minor modification I believe we have consensus on the new ch= arter text. The full charter text is given below if you have any issues with this pleas= e respond within the next week. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D SUGGESTED CHARTER - UPDATE (To 2nd Paragraph) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Session recording is a critical requirement in many business communications= environments such as call centers and financial trading floors. In some of= these environments, all calls must be recorded for regulatory and complian= ce reasons. In others, calls may be recorded for quality control, business = analytics, or consumer protection. Recording is typically done by sending a= copy of the media to the recording devices. The working group will determi= ne requirements and produce a specification for a protocol that will manage= delivery of media, in SIP based systems (including audio, video, MSRP inst= ant message sessions, and real-time text) from an end-point that originates= media, or that has access to it, to a recording device. PBX and recording = vendors today implement proprietary, incompatible mechanisms to facilitate = recording. A standard protocol will reduce the complexity and cost of provi= ding such recording services. =3D=3D=3D=3D=3D=3D=3D=3D=3D END =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D The rest of the charter remains unchanged. The milestone issue will be tackled separately. Regards Andy From nobody Mon Apr 7 21:46:29 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1D01A0104 for ; Mon, 7 Apr 2014 21:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.012 X-Spam-Level: X-Spam-Status: No, score=-7.012 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_62=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTl_zLQdJLIE for ; Mon, 7 Apr 2014 21:46:23 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4F81A00EF for ; Mon, 7 Apr 2014 21:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9760; q=dns/txt; s=iport; t=1396932377; x=1398141977; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=kG+eN7ONcURQpnYma8FyXFrczVIX7qJAEheBi1qKWg4=; b=lUHdgK2Z/L1mmi+xIBUdCres8AXzme10uqyfNiwdIHEMx/WdOZPaXWeJ irCX4M3J9FbWznr2qZPMFB3SGVzOuybVOD5L4k65TybqfSTGSMveSfVWa phIlkx9n8oB8ElmMh0ow2qm/O2Nye4bAUV6408AK0qRfihp1w9Ksvuw2t 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FADF+Q1OtJA2G/2dsb2JhbABZgwY7V4MKuWeGZlEZgQcWdIIlAQEBAwEBAQExNAYXBAIBCBEDAQEBBQgbBQICJQsUCQgCBAESG4dWCA2MRZwQBqIuF4EjjRwQIgICAoJjgU8EmFyBNJEMgzCCKw X-IronPort-AV: E=Sophos;i="4.97,815,1389744000"; d="scan'208";a="33842096" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-3.cisco.com with ESMTP; 08 Apr 2014 04:46:17 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s384kH7m018628 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Apr 2014 04:46:17 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.88]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Mon, 7 Apr 2014 23:46:16 -0500 From: "Ram Mohan R (rmohanr)" To: "finlay.fraser@bt.com" , "Gerben.Stam@nice.com" , "siprec@ietf.org" Thread-Topic: [siprec] SIPREC metadata example comments Thread-Index: AQHPUuV5Gp5R1fY3h0S7uWQHocWdpg== Date: Tue, 8 Apr 2014 04:46:16 +0000 Message-ID: References: <001c01cf3cc1$7b0ce0f0$7126a2d0$@co.in> <67DAF295CD01EB44AE6EA8A51F6ABF0A43559C0758@EMV62-UKRD.domain1.systemhost.net> <002e01cf4dd7$70a76640$51f632c0$@co.in> <67DAF295CD01EB44AE6EA8A51F6ABF0A4357640940@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <67DAF295CD01EB44AE6EA8A51F6ABF0A4357640940@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [72.163.212.123] Content-Type: text/plain; charset="euc-kr" Content-ID: <00582D5565A8C14294ECFD44E8CFCB21@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/PLSeyF7Ky_Qzc2U3nFugXMrl_V4 Subject: Re: [siprec] SIPREC metadata example comments X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 08 Apr 2014 04:46:27 -0000 SW5saW5lIGZvciBzb21lIGNvbW1lbnRzDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiAiZmlubGF5LmZyYXNlckBidC5jb20iIDxmaW5sYXkuZnJhc2VyQGJ0LmNvbT4NCkRhdGU6 IFdlZG5lc2RheSwgMiBBcHJpbCAyMDE0IDI6NDAgcG0NClRvOiAicGFydGhhQHBhcnRoYXNhcmF0 aGkuY28uaW4iIDxwYXJ0aGFAcGFydGhhc2FyYXRoaS5jby5pbj4sIFJhbSBNb2hhbg0KUmF2aW5k cmFuYXRoIDxybW9oYW5yQGNpc2NvLmNvbT4sICJHZXJiZW4uU3RhbUBuaWNlLmNvbSINCjxHZXJi ZW4uU3RhbUBuaWNlLmNvbT4NCkNjOiAic2lwcmVjQGlldGYub3JnIiA8c2lwcmVjQGlldGYub3Jn Pg0KU3ViamVjdDogUkU6IFtzaXByZWNdIFNJUFJFQyBtZXRhZGF0YSBleGFtcGxlIGNvbW1lbnRz DQoNCj5UaGFua3MgZm9yIGdldHRpbmcgYmFjayB0byB1cw0KPg0KPk9uIHRoZSBncm91cHMgd2Ug YXJlIGhhcHB5IHRoYXQgdGhpcyBpcyBhIGNvcnJlY3QgdXNlLg0KPg0KPk9uIHRoZSBjb25mZXJl bmNlIHlvdSBhcmUgc2F5aW5nIHRoaXMgaXMgYW4gYXBwbGljYXRpb24gbGV2ZWwgcHJvYmxlbQ0K DQpZZXMuIEFuIGltcGxlbWVudGF0aW9uIG9mIFNSQyBjYW4gZ2V0IHRoZSBkZXRhaWxzIGluIGRp ZmZlcmVudCB3YXlzLiBJZg0KdGhlIFNSQyBpcyBhbHNvIGEgQ29uZmVyZW5jZSBGb2N1cyBpdCB3 b3VsZCBhbHJlYWR5IGhhdmUgbW9zdCBvZiB0aGUNCmRldGFpbHMgYWJvdXQgcGFydGljaXBhbnQg YW5kIGNhbiBzZW5kIHRoZSBzYW1lIGFzIGEgc25hcHNob3QgaW4gWE1MIHRvDQpTUlMuIEluIGNh c2UgYSBTUkMgaXMgYSBwYXJ0aWNpcGFudCBpbiB0aGUgY29uZmVyZW5jZSBpdCBNQVkgdXNlIFJG QzQ1NzUNCnRvIHN1YnNjcmliZSB0byBhIEZvY3VzIGFuZCBnZXQgdGhlIGRldGFpbHMgb2YgYWxs IHRoZSBwYXJ0aWNpcGFudHMgYmVmb3JlDQppdCBzZW5kcyBYTUwgKFNJUFJFQyBtZXRhZGF0YSkg c25hcHNob3QgdG8gU1JTLg0KDQo+IA0KPg0KPkp1c3QgYXMgYSBiaXQgb2YgYmFja2dyb3VuZCB3 ZSBoYXZlIGRlY2lkZWQgdG8gb25seSByZXBvcnQgZmlyc3QgcGFydHkNCj5jb25uZWN0aW9ucyBh bmQgZGlzY29ubmVjdGlvbnMgdG8gQ1MncyBpbiBhbiBSUy4gU28gb25seSBjb25uZWN0aW9ucyBi eQ0KPmVudGl0aWVzIHJlY29yZGVkIGluIHRoaXMgUlMuIFRoaXMgaGFzIGFsbG93ZWQgdXMgdG8g cmVkdWNlZCB0aGUNCj5leHBvbmVudGlhbCBpbmNyZWFzZSBpbiB0cmFmZmljIGNhdXNlZCBieSBy ZXBvcnRpbmcgYWxsIGNvbm5lY3Rpb24NCj5jaGFuZ2VzIGZvciBhbGwgdXNlcnMgaW4gYSBsYXJn ZSBjb25mZXJlbmNlIHRvIGV2ZXJ5IFJTIGludm9sdmVkLg0KDQpTdXJlLiBJdCBpcyB1cCB0byBh IFNSQyBpbXBsZW1lbnRhdGlvbiBvbiBob3cgb2Z0ZW4vIHdoZW4gaGUgd2FudHMgdG8NCmFkdmVy dGlzZSB0aGUgbWV0YWRhdGEuIEluIGdlbmVyYWwgaXQgaXMgcmVjb21tZW5kZWQgdG8gaW5kaWNh dGUgdGhlDQpjaGFuZ2VzIGluIGEgQ1MgYXMgc29vbiBhcyBwb3NzaWJsZSB0byBhIFNSUyBhcyBT SVBSRUMgaXMgYWxsIGFib3V0IHJlYWwNCnRpbWUgcmVjb3JkaW5nLg0KDQoNCkRvIHlvdSBoYXZl IGFueSBvdGhlciBjb21tZW50cyBvbiB0aGUgbWV0YWRhdGEgZHJhZnQgLQ0KaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zaXByZWMtbWV0YWRhdGEuIElmIHllcyBw bGVhc2UNCmxldCB1cyBrbm93Lg0KDQpSZWdhcmRzLA0KUmFtDQoNCj4NCj5GaW5sYXkgRnJhc2Vy DQo+QW5uYW5kYWxlIEhvdXNlDQo+MSBIYW53b3J0aCBSb2FkDQo+U3VuYnVyeSBvbiBUaGFtZXMN Cj5UVzE2IDVESg0KPkJUIElQIFRlbDogKzQ0ICgwKTE5MzI3NzMzMTAgfCBNb2I6ICs0NCgwKTc3 MTE4NjAyMjggfCBFOg0KPmZpbmxheS5mcmFzZXJAYnQuY29tDQo+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPkZyb206IFBhcnRoYXNhcmF0aGkgUiBbcGFydGhhQHBh cnRoYXNhcmF0aGkuY28uaW5dDQo+U2VudDogMDEgQXByaWwgMjAxNCAxOToyMw0KPlRvOiAnUmFt IE1vaGFuIFIgKHJtb2hhbnIpJzsgRnJhc2VyLEZKLEZpbmxheSxKUk0xMyBSOw0KPkdlcmJlbi5T dGFtQG5pY2UuY29tDQo+Q2M6IHNpcHJlY0BpZXRmLm9yZw0KPlN1YmplY3Q6IFJFOiBbc2lwcmVj XSBTSVBSRUMgbWV0YWRhdGEgZXhhbXBsZSBjb21tZW50cw0KPg0KPkhpIEZpbmxheS9HZXJiZW4s DQo+DQo+SG9wZSB0aGUgYmVsb3cgcmVwbHkgYWRkcmVzc2VzIHlvdXIgY29uY2Vybi4NCj4NCj5B bHNvLCBJJ20gaW50ZXJlc3RlZCBpbiBrbm93aW5nIHdoZXRoZXIgeW91IGhhdmUgYW55IG90aGVy IGlzc3VlcyByZWxhdGVkDQo+dG8NCj5TSVBSRUMgbWV0YWRhdGEgd2hpY2ggaGFzIHRvIGJlIGRp c2N1c3NlZCBiZWZvcmUgV0dMQyBvZiB0aGUgZHJhZnQuDQo+DQo+VGhhbmtzDQo+UGFydGhhDQo+ DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogUmFtIE1vaGFuIFIgKHJt b2hhbnIpIFttYWlsdG86cm1vaGFuckBjaXNjby5jb21dDQo+PiBTZW50OiBUdWVzZGF5LCBNYXJj aCAxMSwgMjAxNCA1OjE4IFBNDQo+PiBUbzogZmlubGF5LmZyYXNlckBidC5jb207IHBhcnRoYUBw YXJ0aGFzYXJhdGhpLmNvLmluOw0KPj4gR2VyYmVuLlN0YW1AbmljZS5jb20NCj4+IENjOiBzaXBy ZWNAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbc2lwcmVjXSBTSVBSRUMgbWV0YWRhdGEgZXhh bXBsZSBjb21tZW50cw0KPj4NCj4+IFBsZWFzZSBzZWUgaW5saW5lIGZvciBzb21lIGNvbW1lbnRz DQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206ICJmaW5sYXkuZnJh c2VyQGJ0LmNvbSIgPGZpbmxheS5mcmFzZXJAYnQuY29tPg0KPj4gRGF0ZTogVHVlc2RheSwgMTEg TWFyY2ggMjAxNCAxOjU5IHBtDQo+PiBUbzogInBhcnRoYUBwYXJ0aGFzYXJhdGhpLmNvLmluIiA8 cGFydGhhQHBhcnRoYXNhcmF0aGkuY28uaW4+LA0KPj4gIkdlcmJlbi5TdGFtQG5pY2UuY29tIiA8 R2VyYmVuLlN0YW1AbmljZS5jb20+DQo+PiBDYzogInNpcHJlY0BpZXRmLm9yZyIgPHNpcHJlY0Bp ZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJlOiBbc2lwcmVjXSBTSVBSRUMgbWV0YWRhdGEgZXhhbXBs ZSBjb21tZW50cw0KPj4NCj4+ID5QYXJ0aGENCj4+ID4NCj4+ID5BcmUgeW91IHNheWluZyBSRkM0 NTc1IGlzIG1hbmRhdG9yeSBwYWNrYWdlIGZvciBTSVBSRUMgc3VwcG9ydCBhbmQNCj4+IHdvdWxk DQo+PiA+aGF2ZSB0byBiZSBhdmFpbGFibGUuDQo+Pg0KPj4gTm8uIFNJUFJFQyBkb2VzIG5vdCBt YW5kYXRlIHlvdSB0byBoYXZlIFJGQzQ1NzUuIEl0IGlzIHVwIHRvIHRoZSBTUkMNCj4+IChwYXJ0 aWNpcGFudCBpbiB0aGUgY29uZmVyZW5jZSBpbiB0aGlzIGV4YW1wbGUpIHRvIGxlYXJuIHRoZSBk ZXRhaWxzIG9mDQo+PiB0aGUgb3RoZXIgcGFydGljaXBhbnQgaW4gdGhlIGNvbmZlcmVuY2Ugc2Vz c2lvbiBiZWZvcmUgaXQgc2VuZHMNCj4+IHNuYXBzaG90DQo+PiBvZiBtZXRhZGF0YSB0byBTUlMu IEl0IG1heSB1c2UgUkZDNDU3NSBtZXRob2QgYnkgc3Vic2NyaWJpbmcgdG8gYQ0KPj4gY29uZmVy ZW5jZSBmb2N1cyBvciB1c2Ugc29tZSBvdGhlciBtZWFucyB0byBnZXQgdGhlIGRldGFpbHMuIFdl IGFyZSBub3QNCj4+IG1hbmRhdGluZyB0byB1c2UgUkZDNDU3NSBvbmx5Lg0KPj4NCj4+IFNJUFJF QyBvbmx5IHRhbGtzIGFib3V0IGhvdyBhIFNSQyBzZW5kcyh0aGUgcHJvdG9jb2wgc2VtYW50aWNz KQ0KPj4gbWV0YWRhdGENCj4+IHRvIFNSUyBhbmQgc2VtYW50aWNzIG9mIG1ldGFkYXRhKFhNTCBz Y2hlbWEpLiBIb3cgU1JDIGdldHMgdGhlDQo+PiBpbmZvcm1hdGlvbg0KPj4gdGhhdCBmaWxscyB1 cCBtZXRhZGF0YSBpcyBwdXJlbHkgYSBhcHBsaWNhdGlvbiBsb2dpYyBhbmQgSU1PIG5lZWQgbm90 DQo+PiBiZQ0KPj4gZGVmaW5lZCBpbiB0aGUgb24td2lyZSBwcm90b2NvbC4NCj4+DQo+PiA+DQo+ PiA+SWYgbm90IGFuZCB0aGVyZSBpcyBubyBSRkM0NTc1IGZlZWQgYXZhaWxhYmxlIGhvdyBkb2Vz IHRoZSBwYXJ0aWNpcGFudA0KPj4gPmtub3cgYWJvdXQgYWxsIHRoZSBvdGhlciBwYXJ0aWVzIGFu ZCB0aGVpciBzdGF0ZSBpZiB0aGV5IGFyZSBub3Qgc2VudA0KPj4gaW4NCj4+ID50aGUgTWV0YWRh dGEgVVBEQVRFDQo+PiA+DQo+PiA+T3IgaGF2ZSBJIG1pc3NlZCB0aGUgbWVhbmluZyBvZiB0aGUg cGFyYWdyYXBoDQo+PiA+DQo+PiA+T24gdGhlIHVzZSBvZiBncm91cHMgaW4gdHJhZGluZw0KPj4g Pg0KPj4gPldlIGhhdmUgYSB1c2UgY2FzZSB3aGVyZSB0d28gY29tbXVuaWNhdGlvbiBzZXNzaW9u cyB0aGF0IGFyZQ0KPj4gZXN0YWJsaXNoZWQNCj4+ID53aXRoIG9uZSBvciBtb3JlIHBhcnRpZXMg bWVyZ2UgdG9nZXRoZXIgdG8gZm9ybSBhIHNpbmdsZSBjYWxsLiBXZSBuZWVkDQo+PiBhDQo+PiA+ d2F5IHRvIHRhZyBhbGwgbGVncyBvZiB0aGUgY2FsbCB0byBpbmRpY2F0ZSB0aGlzLiBUbyBkbyB0 aGlzIHdlDQo+PiBwcm9wb3NlDQo+PiA+dG8gdXNlIEdyb3VwIHNvIHRoZSB0d28gQ1Mgd2lsbCBz dGF5IHRoZSBzYW1lIGJ1dCBib3RoIHdpbGwgbm93IHNoYXJlDQo+PiBhDQo+PiA+Z3JvdXAgdGFn Lg0KPj4NCj4+IFllcy4gQ1MtZ3JvdXAgaXMgc3BlY2lmaWNhbGx5IGlzIG1lYW50IGZvciB0aGlz IHB1cnBvc2UuIElmIGENCj4+IGFwcGxpY2F0aW9uDQo+PiB3YW50cyB0byBsaW5rIHR3byBDU6n2 cyBpdCBjYW4gdXNlIHRoaXMgQ1MtZ3JvdXAgYW5kIHRhZyB0aGVtIHRvZ2V0aGVyLg0KPj4gWW91 ciB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3QgaGVyZS4NCj4+DQo+PiBSZWdhcmRzLA0KPj4gUmFt DQo+Pg0KPj4gPg0KPj4gPk5vdGUgaXQgaXMgYWxzbyBwb3NzaWJsZSBmb3IgbWVyZ2UgY2FsbHMg dG8gYmUgbWVyZ2VkLiBXaGVuIHRoaXMNCj4+IGhhcHBlbnMNCj4+ID5hIG5ldyBncm91cCB0YWcg d2lsbCBiZSBhZGRlZC4NCj4+ID5JbiB0aGlzIHdheSBhIFZSIGNhbiBmaW5kIG9yaWdpbmFsIENT IGFuZCBiZSBhd2FyZSB0aGF0IGl0IHdhcyBtZXJnZWQNCj4+IGFuZA0KPj4gPmZyb20gdGhlIG1l cmdlIHRhZ3MgaXQgY2FuIGxvY2F0ZSBhbGwgb3RoZXIgcGFydGllcyBpbiB0aGUgY2FsbC4NCj4+ ID4NCj4+ID5JZiB0aGVyZSBpcyBhIGJldHRlciB3YXkgdG8gZGVhbCB3aXRoIHRoaXMgcGxlYXNl cyBsZXQgbWUga25vdy4NCj4+ID4NCj4+ID4NCj4+ID5GaW5sYXkgRnJhc2VyDQo+PiA+QW5uYW5k YWxlIEhvdXNlDQo+PiA+MSBIYW53b3J0aCBSb2FkDQo+PiA+U3VuYnVyeSBvbiBUaGFtZXMNCj4+ ID5UVzE2IDVESg0KPj4gPkJUIElQIFRlbDogKzQ0ICgwKTE5MzI3NzMzMTAgfCBNb2I6ICs0NCgw KTc3MTE4NjAyMjggfCBFOg0KPj4gPmZpbmxheS5mcmFzZXJAYnQuY29tDQo+PiA+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPkZyb206IHNpcHJlYyBbc2lwcmVj LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYXJ0aGFzYXJhdGhpIFINCj4+ID5bcGFy dGhhQHBhcnRoYXNhcmF0aGkuY28uaW5dDQo+PiA+U2VudDogMTEgTWFyY2ggMjAxNCAwMDozMw0K Pj4gPlRvOiBHZXJiZW4uU3RhbUBuaWNlLmNvbQ0KPj4gPkNjOiBzaXByZWNAaWV0Zi5vcmcNCj4+ ID5TdWJqZWN0OiBbc2lwcmVjXSBTSVBSRUMgbWV0YWRhdGEgZXhhbXBsZSBjb21tZW50cw0KPj4g Pg0KPj4gPkhpIEdlcmJlbiwNCj4+ID4NCj4+ID5JbiBJRVRGLTg5IFNJUFJFQyBtZWV0aW5nLCB5 b3UgaGF2ZSBtZW50aW9uZWQgYWJvdXQgdHdvIGlzc3VlcyByZWxhdGVkDQo+PiB0bw0KPj4gPlNJ UlBFQyBtZXRhZGF0YQ0KPj4gPg0KPj4gPjEpIFRyYWRpbmcgc2NlbmFyaW8gd2hlcmVpbiB0aGUg cGFydGljaXBhbnQgYWRkZWQvcmVtb3ZlZCB2ZXJ5IHF1aWNrbHkNCj4+IGFzDQo+PiA+aXQNCj4+ ID5pcyBjb25mZXJlbmNlLiBIZXJlIHRoZSBjb25jZXJuIGlzIHRoYXQgYWxsIHBhcnRpY2lwYW50 IGFyZSByZXF1aXJlZA0KPj4gdG8gYmUNCj4+ID5mb3J3YXJkZWQgU1JDIHRvIFNSUyB3aGVuZXZl ciB0aGVyZSBpcyBhIGNoYW5nZSBpbiBwYXJ0aWNpcGFudHMuDQo+PiA+DQo+PiA+PFNvbHV0aW9u PiBTZWMgMy4zLjMgb2YNCj4+ID5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXNpcHJlYy1jYWxsZmxvd3MtMDIjcGFnZS0yNA0KPj4gZXhwbGFpbnMNCj4+ID5ob3cgdG8gYWRk L3JlbW92ZSBwYXJ0aWNpcGFudCB3aXRob3V0IHNlbmRpbmcgZXZlcnkgcGFydGljaXBhbnQuDQo+ PiBQbGVhc2UNCj4+ID5sZXQNCj4+ID5tZSBrbm93IGluIGNhc2UgeW91IGhhdmUgYW55IGRpZmZp Y3VsdGllcyBpbiB1c2luZyB0aGlzIHNvbHV0aW9uLg0KPj4gPjwvc29sdXRpb24+DQo+PiA+DQo+ PiA+MikgR3JvdXAgaXMgaW50ZXJwcmV0ZWQgZGlmZmVyZW50bHkgaW4gdHJhZGluZyBzY2VuYXJp by4NCj4+ID4NCj4+ID5QbGVhc2UgbG9vayBpbnRvIFNlYyAzLjUgb2YNCj4+ID5odHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNpcHJlYy1jYWxsZmxvd3MtMDIjcGFnZS0yOCBh cw0KPj4gaXQNCj4+ID5pcyBhDQo+PiA+dHJhZGluZyBzY2VuYXJpbyB0byB1bmRlcnN0YW5kIHRo ZSBvbmUgb2YgdGhlIHBvc3NpYmxlIHVzYWdlIHdpdGgNCj4+IGdyb3VwLg0KPj4gPkhhdmluZyBz YWlkIHRoYXQsIEknbSBub3QgdmVyeSBjbGVhciBhYm91dCB5b3VyIHByb2JsZW0gc3RhdGVtZW50 Lg0KPj4gUGxlYXNlDQo+PiA+Y2xhcmlmeSBpbiBjYXNlIEkgZGlkbid0IHVuZGVyc3RhbmQgeW91 ciBjb25jZXJuLg0KPj4gPg0KPj4gPlRoYW5rcw0KPj4gPlBhcnRoYQ0KPj4gPg0KPj4gPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+c2lwcmVjIG1h aWxpbmcgbGlzdA0KPj4gPnNpcHJlY0BpZXRmLm9yZw0KPj4gPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2lwcmVjDQo+PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+ID5zaXByZWMgbWFpbGluZyBsaXN0DQo+PiA+c2lwcmVj QGlldGYub3JnDQo+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBy ZWMNCg0K From nobody Tue Apr 8 09:45:55 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865B21A064A for ; Tue, 8 Apr 2014 09:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H67M11ZDVZ-D for ; Tue, 8 Apr 2014 09:45:50 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 446051A058E for ; Tue, 8 Apr 2014 09:45:22 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta10.westchester.pa.mail.comcast.net with comcast id nQ7g1n00J1ei1Bg5AUlN7d; Tue, 08 Apr 2014 16:45:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id nUlM1n00f3ZTu2S3kUlNiM; Tue, 08 Apr 2014 16:45:22 +0000 Message-ID: <534427A1.3040209@alum.mit.edu> Date: Tue, 08 Apr 2014 12:45:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: siprec@ietf.org References: <9F33F40F6F2CD847824537F3C4E37DDF17C8D262@MCHP04MSX.global-ad.net> <52C58B5F.6040400@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF17D69BCD@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17D69BCD@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1396975522; bh=W+6YRnKpsuvq6IOW8F2eZQFdiodSbnoCSkYG+TtlqM0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=a0Bh6uByQRXsTTEcPqlUfBb9cZB5n6jrgYxvK+9afA4R7Hbi1gLsJEUTZOBAq5Xnl vkR5aJ/U3C5OusiXN0X88+rueDb379vwRIP1XrAp83vAGUKUiMDO2jhxN6rv39Ca8a sNvMNPwjC51LSu8jTH2qxOAiGjqMgqvmKRBwftq4QATlILmSM61Iky2JPm0iU+sy0r CgQT9d+SmrstRxd3Ww86KrQaJiO88r6vvMUNpK2SnE8ksZeWGt+iNLHZR32zc0ZrcW t7JCV/frJMJA0/B8BLgekQh/xYgYN8ZU2FKr7otTjqTKhS3ZScaOS/ltD0UIfecuYw vc6ssiioN+qZA== Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/tO1Qi1dlF5B0p-hCgDDaymJismU Subject: Re: [siprec] Confirming Consensus on SIPREC Charter Update. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 08 Apr 2014 16:45:52 -0000 This seems ok to me. But in reading it again, it seems to me that the order of the text is not quite right. The parenthetic list that not includes RTT is a list of *media types*, so it would be clearer if it modified "media" rather than "SIP based systems". Here is a version with that change: ============================================== SUGGESTED CHARTER - UPDATE (To 2nd Paragraph) (phk) ============================================= Session recording is a critical requirement in many business communications environments such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control, business analytics, or consumer protection. Recording is typically done by sending a copy of the media to the recording devices. The working group will determine requirements and produce a specification for a protocol that will manage delivery of media (including audio, video, MSRP instant message sessions, and real-time text), in SIP based systems from an end-point that originates media, or that has access to it, to a recording device. PBX and recording vendors today implement proprietary, incompatible mechanisms to facilitate recording. A standard protocol will reduce the complexity and cost of providing such recording services. ========= END =================== The reordering of the text is the only change. Thanks, Paul On 4/7/14 8:59 AM, Hutton, Andrew wrote: > Hi All, > > During the discussion at IETF89 it was pointed out that in clarifying the scope of SIPREC we should have mentioned real-time text so I have added RTT to the list of media within scope in the proposed update to the charter. > > Following this minor modification I believe we have consensus on the new charter text. > > The full charter text is given below if you have any issues with this please respond within the next week. > > > ============================================== > SUGGESTED CHARTER - UPDATE (To 2nd Paragraph) > ============================================= > > Session recording is a critical requirement in many business communications environments such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control, business analytics, or consumer protection. Recording is typically done by sending a copy of the media to the recording devices. The working group will determine requirements and produce a specification for a protocol that will manage delivery of media, in SIP based systems (including audio, video, MSRP instant message sessions, and real-time text) from an end-point that originates media, or that has access to it, to a recording device. PBX and recording vendors today implement proprietary, incompatible mechanisms to facilitate recording. A standard protocol will reduce the complexity and cost of providing such recording services. > > ========= END =================== > > The rest of the charter remains unchanged. > > The milestone issue will be tackled separately. > > > Regards > Andy > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From nobody Tue Apr 8 19:45:41 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327EC1A07A7 for ; Tue, 8 Apr 2014 19:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.874 X-Spam-Level: X-Spam-Status: No, score=-7.874 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gh1LCF-W4b9B for ; Tue, 8 Apr 2014 19:45:37 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 976AB1A0041 for ; Tue, 8 Apr 2014 19:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4432; q=dns/txt; s=iport; t=1397011536; x=1398221136; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=RSVaApNwq/QGQg5ukG6dpWsoyn91O13In/oX1RnNlXc=; b=WvmHRmCgvB+eFmrfYyRxG5hXAIuiRbhiW01NdKpGPV7a6biiNMydjbVA 3eQXNtzthQA0KR06pJu2V/Pv9dj8Tg7CU7rvfVHTDjEcj5KhRHWU7Uw/r I1JZOPYtoUE4ZGOdcqZiRi48yAEjXUfexPRxGpISCx9rhDFrPh+IVTaIO Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAPmzRFOtJV2Z/2dsb2JhbABZgwY7V70DhmRRgRgWdIIlAQEBBAEBATc0FwQCAQgRAwECAR4QJwsdCAIEE4d8DcpxEwSOOToGhDIElHCDbZJBgzCCKw X-IronPort-AV: E=Sophos;i="4.97,822,1389744000"; d="scan'208";a="34173088" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP; 09 Apr 2014 02:45:31 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s392jXiv028466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 9 Apr 2014 02:45:33 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.95]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Tue, 8 Apr 2014 21:45:32 -0500 From: "Ram Mohan R (rmohanr)" To: "siprec@ietf.org" Thread-Topic: [siprec] Confirming Consensus on SIPREC Charter Update. Thread-Index: AQHPU53FxdMdBmZ43UKfXLFejilk3Q== Date: Wed, 9 Apr 2014 02:45:31 +0000 Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF17C8D262@MCHP04MSX.global-ad.net> <52C58B5F.6040400@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF17D69BCD@MCHP04MSX.global-ad.net> <534427A1.3040209@alum.mit.edu> In-Reply-To: <534427A1.3040209@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [72.163.212.123] Content-Type: text/plain; charset="us-ascii" Content-ID: <83D7D2192D6CD146976B0D80AAA9DFCF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/6EYqzoJ8xJKgM3_a0eRHw2QG-dA Subject: Re: [siprec] Confirming Consensus on SIPREC Charter Update. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 09 Apr 2014 02:45:40 -0000 Updated text looks good to me. Regards, Ram -----Original Message----- From: Paul Kyzivat Date: Tuesday, 8 April 2014 10:15 pm To: "siprec@ietf.org" Subject: Re: [siprec] Confirming Consensus on SIPREC Charter Update. >This seems ok to me. But in reading it again, it seems to me that the >order of the text is not quite right. The parenthetic list that not >includes RTT is a list of *media types*, so it would be clearer if it >modified "media" rather than "SIP based systems". Here is a version with >that change: > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >SUGGESTED CHARTER - UPDATE (To 2nd Paragraph) (phk) >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Session recording is a critical requirement in many business >communications environments such as call centers and financial trading >floors. In some of these environments, all calls must be recorded for >regulatory and compliance reasons. In others, calls may be recorded for >quality control, business analytics, or consumer protection. Recording >is typically done by sending a copy of the media to the recording >devices. The working group will determine requirements and produce a >specification for a protocol that will manage delivery of media >(including audio, video, MSRP instant message sessions, and real-time >text), in SIP based systems from an end-point that originates media, or >that has access to it, to a recording device. PBX and recording vendors >today implement proprietary, incompatible mechanisms to facilitate >recording. A standard protocol will reduce the complexity and cost of >providing such recording services. > >=3D=3D=3D=3D=3D=3D=3D=3D=3D END =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > >The reordering of the text is the only change. > > Thanks, > Paul > > >On 4/7/14 8:59 AM, Hutton, Andrew wrote: >> Hi All, >> >> During the discussion at IETF89 it was pointed out that in clarifying >>the scope of SIPREC we should have mentioned real-time text so I have >>added RTT to the list of media within scope in the proposed update to >>the charter. >> >> Following this minor modification I believe we have consensus on the >>new charter text. >> >> The full charter text is given below if you have any issues with this >>please respond within the next week. >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> SUGGESTED CHARTER - UPDATE (To 2nd Paragraph) >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Session recording is a critical requirement in many business >>communications environments such as call centers and financial trading >>floors. In some of these environments, all calls must be recorded for >>regulatory and compliance reasons. In others, calls may be recorded for >>quality control, business analytics, or consumer protection. Recording >>is typically done by sending a copy of the media to the recording >>devices. The working group will determine requirements and produce a >>specification for a protocol that will manage delivery of media, in SIP >>based systems (including audio, video, MSRP instant message sessions, >>and real-time text) from an end-point that originates media, or that has >>access to it, to a recording device. PBX and recording vendors today >>implement proprietary, incompatible mechanisms to facilitate recording. >>A standard protocol will reduce the complexity and cost of providing >>such recording services. >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D END =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> >> The rest of the charter remains unchanged. >> >> The milestone issue will be tackled separately. >> >> >> Regards >> Andy >> >> >> >> _______________________________________________ >> 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 nobody Tue Apr 22 04:59:15 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A641A03DA for ; Tue, 22 Apr 2014 04:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.528 X-Spam-Level: X-Spam-Status: No, score=0.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZNqTrixP9vj for ; Tue, 22 Apr 2014 04:59:10 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id AA78D1A03B8 for ; Tue, 22 Apr 2014 04:59:09 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 4CEB323F03FA; Tue, 22 Apr 2014 13:59:03 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.60]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0174.001; Tue, 22 Apr 2014 13:59:03 +0200 From: "Hutton, Andrew" To: "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Thread-Topic: [siprec] Confirming Consensus on SIPREC Charter Update. Thread-Index: AQHPBh2Hk9hG1GEB8kaXnfAFAr7O5ZseN73w Date: Tue, 22 Apr 2014 11:59:02 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17D7A024@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF17C8D262@MCHP04MSX.global-ad.net> <52C58B5F.6040400@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF17D69BCD@MCHP04MSX.global-ad.net> <534427A1.3040209@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/rAiyZWcVzR2zyhIVTGZRgO9n-vs Subject: Re: [siprec] Confirming Consensus on SIPREC Charter Update. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 11:59:14 -0000 +1 Will go ahead and get the AD's to make this change to the charter using = the text that Paul suggested. Andy > -----Original Message----- > From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R > (rmohanr) > Sent: 09 April 2014 03:46 > To: siprec@ietf.org > Subject: Re: [siprec] Confirming Consensus on SIPREC Charter Update. >=20 > Updated text looks good to me. >=20 > Regards, > Ram >=20 > -----Original Message----- > From: Paul Kyzivat > Date: Tuesday, 8 April 2014 10:15 pm > To: "siprec@ietf.org" > Subject: Re: [siprec] Confirming Consensus on SIPREC Charter Update. >=20 > >This seems ok to me. But in reading it again, it seems to me that the > >order of the text is not quite right. The parenthetic list that not > >includes RTT is a list of *media types*, so it would be clearer if it > >modified "media" rather than "SIP based systems". Here is a version > with > >that change: > > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >SUGGESTED CHARTER - UPDATE (To 2nd Paragraph) (phk) > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >Session recording is a critical requirement in many business > >communications environments such as call centers and financial trading > >floors. In some of these environments, all calls must be recorded for > >regulatory and compliance reasons. In others, calls may be recorded > for > >quality control, business analytics, or consumer protection. Recording > >is typically done by sending a copy of the media to the recording > >devices. The working group will determine requirements and produce a > >specification for a protocol that will manage delivery of media > >(including audio, video, MSRP instant message sessions, and real-time > >text), in SIP based systems from an end-point that originates media, > or > >that has access to it, to a recording device. PBX and recording > vendors > >today implement proprietary, incompatible mechanisms to facilitate > >recording. A standard protocol will reduce the complexity and cost of > >providing such recording services. > > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D END =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > > >The reordering of the text is the only change. > > > > Thanks, > > Paul > > > > > >On 4/7/14 8:59 AM, Hutton, Andrew wrote: > >> Hi All, > >> > >> During the discussion at IETF89 it was pointed out that in > clarifying > >>the scope of SIPREC we should have mentioned real-time text so I have > >>added RTT to the list of media within scope in the proposed update to > >>the charter. > >> > >> Following this minor modification I believe we have consensus on the > >>new charter text. > >> > >> The full charter text is given below if you have any issues with > this > >>please respond within the next week. > >> > >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> SUGGESTED CHARTER - UPDATE (To 2nd Paragraph) > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> Session recording is a critical requirement in many business > >>communications environments such as call centers and financial > trading > >>floors. In some of these environments, all calls must be recorded for > >>regulatory and compliance reasons. In others, calls may be recorded > for > >>quality control, business analytics, or consumer protection. > Recording > >>is typically done by sending a copy of the media to the recording > >>devices. The working group will determine requirements and produce a > >>specification for a protocol that will manage delivery of media, in > SIP > >>based systems (including audio, video, MSRP instant message sessions, > >>and real-time text) from an end-point that originates media, or that > has > >>access to it, to a recording device. PBX and recording vendors today > >>implement proprietary, incompatible mechanisms to facilitate > recording. > >>A standard protocol will reduce the complexity and cost of providing > >>such recording services. > >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D END =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > >> > >> The rest of the charter remains unchanged. > >> > >> The milestone issue will be tackled separately. > >> > >> > >> Regards > >> Andy > >> > >> > >> > >> _______________________________________________ > >> 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 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec