From john.2.stafford@bt.com Thu Mar 1 00:53:08 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2757921F8649 for ; Thu, 1 Mar 2012 00:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.985 X-Spam-Level: X-Spam-Status: No, score=-2.985 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O30vBegRmN6e for ; Thu, 1 Mar 2012 00:53:07 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id A2ECB21F8644 for ; Thu, 1 Mar 2012 00:53:04 -0800 (PST) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 1 Mar 2012 08:53:03 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.172]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Thu, 1 Mar 2012 08:53:03 +0000 From: To: , , Date: Thu, 1 Mar 2012 08:53:03 +0000 Thread-Topic: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream Thread-Index: AQHM9u5+fndjjd+/FkOIx8G3Z8JvJpZToyqAgAAsYgCAANXBkIAAexry Message-ID: References: , <4F4E43D3.8070508@alum.mit.edu> , <387F9047F55E8C42850AD6B3A7A03C6C0E068E45@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E068E45@inba-mail01.sonusnet.com> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 08:53:08 -0000 Partha, I cant see how using CSG will help with the describing of the streams. =20 Also I'm not convinced this would be the correct usage of a CSG, as while t= he calls are associated as they are made by the same person, in terms of si= p they are completely unrelated. I think draft-ietf-metadata could do with an explanation of what relationsh= ips a CSG implies. Rgds John Stafford | Solution Architect 1 | BT Global Services=20 ________________________________________ From: Ravindran, Parthasarathi [pravindran@sonusnet.com] Sent: 01 March 2012 01:31 To: Stafford,J,John,JRJ3X C; pkyzivat@alum.mit.edu; siprec@ietf.org Subject: RE: [siprec] How to specify in metadata that multiple CS's are bei= ng recorded in a single mixed RS m line stream John, I guess that you are looking for group (CSG) element usage. Person AC sessi= ons has to be grouped under single group. CS AC-B has to be mentioned as on= e of the session in group and CS AC-D has to be mentioned as another sessio= n of the group. Here, user AC is available in both sessions wherein partici= pant (device) A is in session1 and participant (device) C is in session2, i= t is possible to pass participant name as AC in both sessions and it is per= fectly fine. Please let me know whether this approach solves your problem. Thanks Partha >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of john.2.stafford@bt.com >Sent: Wednesday, February 29, 2012 11:36 PM >To: pkyzivat@alum.mit.edu; siprec@ietf.org >Subject: Re: [siprec] How to specify in metadata that multiple CS's are >being recorded in a single mixed RS m line stream > >Paul, > >Its one person AC with two handsets both in use at same time, probably >one to each ear. > >Rgds >John Stafford | Solution Architect 1 | BT Global Services >________________________________________ >From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of >Paul Kyzivat [pkyzivat@alum.mit.edu] >Sent: 29 February 2012 15:27 >To: siprec@ietf.org >Subject: Re: [siprec] How to specify in metadata that multiple CS's are >being recorded in a single mixed RS m line stream > >On 2/29/12 9:29 AM, john.2.stafford@bt.com wrote: >> A converse of the "How to specify in metadata that a participants >stream is being recorded in multiple m line streams" thread: >> >> Another of our record configurations is when a turret's handset 1 and >> handset 2 calls are recorded as a single mixed recorder stream >> >> once again a persistent RS will be set up at registration time, in >this case there will be a single m line. >> >> So if represents a record stream, how would the following be >described in metadata: >> >> There are 2 calls, A-B and C-D, both are recorded via a single >stream. >> participants A and C are the same person, making two calls on handset >1 and handset 2 of their turret. > >Just to clarify: > >There is one person, call him AC, that has two handsets A and C. >AC has established one call with B (CS-A-B) and another call with D (CS- >C-D). > >I gather these calls go on in parallel. (Maybe AC is switching back and >forth taking into one handset of the other. In principal he could put >one to each ear and use both at the same time.) > >Or is this more like a two line phone, with radio buttons to switch >between the two lines, so that at any given time one is active and the >other is "on hold"? > >I won't even try to respond to the stuff below until I get clarity on >the above. > > Thanks, > Paul > >> The problems I have in describing this in metadata are: >> 1. I dont know how to show what the participants, as they dont >recv the 2 call mixed stream. >> 2. I only have a single stream being recorded which includes 2 CS's, >> but the element can only have a single session attriibute >> >> I can only describe this using >and. I have not been following the list too >closely for the past couple of months, is it still the intention to use >these elements, as I see there is not yet a draft-ietf-metadata-06.txt >that includes these elements in xml schema and examples. >> >> Also I dont know what happens to when using >associations. >> >> Anyway, heres my stab at it, >> >> >> >> complete >> >> >> > id=3D"=3D=3DPARTICIPANT_A=3D=3D" >> >> RamMohan R >> >> >> > participant=3D"=3D=3DPARTICIPANT_A=3D=3D" >> session=3D"=3D=3D=3D=3DSESSION_ONE=3D=3D=3D=3D=3D"> >> 2010-12-16T23:41:07Ztime> >> TBD >> >> > participant=3D"=3D=3DPARTICIPANT_A=3D=3D" >> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> >> 2010-12-16T23:41:07Ztime> >> >> >> > id=3D"=3D=3DPARTICIPANT_B=3D=3D" >> >> Paul Kyzivat >> >> >> > participant=3D"=3D=3DPARTICIPANT_B=3D=3D" >> session=3D"=3D=3D=3D=3DSESSION_ONE=3D=3D=3D=3D=3D"> >> 2010-12-16T23:41:07Ztime> >> TBD >> >> > participant=3D"=3D=3DPARTICIPANT_B=3D=3D" >> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> >> 2010-12-16T23:41:07Ztime> >> >> >> >> >> >> > id=3D"=3D=3DPARTICIPANT_C=3D=3D" >> >> RamMohan R >> >> >> > participant=3D"=3D=3DPARTICIPANT_C=3D=3D" >> session=3D"=3D=3D=3D=3DSESSION_TWO=3D=3D=3D=3D=3D"> >> 2010-12-16T22:02:04Ztime> >> TBD >> >> > participant=3D"=3D=3DPARTICIPANT_C=3D=3D" >> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> >> 2010-12-16T22:02:04Ztime> >> >> >> > id=3D"=3D=3DPARTICIPANT_D=3D=3D" >> >> Andrew >Hutton >> >> >> > participant=3D"=3D=3DPARTICIPANT_D=3D=3D" >> session=3D"=3D=3D=3D=3DSESSION_TWO=3D=3D=3D=3D=3D"> >> 2010-12-16T22:02:04Ztime> >> TBD >> >> > participant=3D"=3D=3DPARTICIPANT_D=3D=3D" >> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> >> 2010-12-16T22:02:04Ztime> >> >> >> > >> >> >> >> >> Rgds >> John Stafford | Solution Architect 1 | BT Global Services >> _______________________________________________ >> 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 Thu Mar 1 07:20:53 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3242F21E801F for ; Thu, 1 Mar 2012 07:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFeBb0hpLkkw for ; Thu, 1 Mar 2012 07:20:52 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 626BE21E81BE for ; Thu, 1 Mar 2012 07:20:52 -0800 (PST) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id E964623F0571; Thu, 1 Mar 2012 16:20:50 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 1 Mar 2012 16:20:51 +0100 From: "Hutton, Andrew" To: "Charles Eckel (eckelcu)" , Henry Lum , "brian.rosen@gmail.com" Date: Thu, 1 Mar 2012 16:20:49 +0100 Thread-Topic: SIPREC Protocol draft and merge of draft-eckel-siprec-rtp-rec-03 Thread-Index: Acz3vuHI0BO7jot3SmO9nq+Y5OInxA== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312945D5928@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 Cc: "siprec@ietf.org" Subject: [siprec] SIPREC Protocol draft and merge of draft-eckel-siprec-rtp-rec-03 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 15:20:53 -0000 Hi All, We still have a place holder in draft-ietf-siprec-protocol for including te= xt from draft-eckel-siprec-rtp-rec-03. What is holding is up with this do we need more review from AVT experts or = is it something else? I see from the Taipei minutes that "section 4.3 needs more text about vario= us usages of RTP by mixers/translators". Charles, can you initiate discussion on the list to move this forward or le= t me know what other action we need to take. Regards Andy (SIPREC Co-Chair). From gonzalo.camarillo@ericsson.com Thu Mar 1 09:19:44 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E8721F8961 for ; Thu, 1 Mar 2012 09:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.293 X-Spam-Level: X-Spam-Status: No, score=-110.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yg03tVmWmy6U for ; Thu, 1 Mar 2012 09:19:44 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 213A221E8066 for ; Thu, 1 Mar 2012 09:19:42 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-2c-4f4fafaecad3 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FF.EC.27041.EAFAF4F4; Thu, 1 Mar 2012 18:19:42 +0100 (CET) Received: from [131.160.126.136] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Mar 2012 18:19:41 +0100 Message-ID: <4F4FAFAC.5080300@ericsson.com> Date: Thu, 1 Mar 2012 19:19:40 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Leon Portman References: <4F4CBD98.9010801@ericsson.com> <101C6067BEC68246B0C3F6843BCCC1E3129455FFFB@MCHP058A.global-ad.net> <07465C1D981ABC41A344374066AE1A2C39DA5268F9@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C39DA5268F9@TLVMBX01.nice.com> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "siprec@ietf.org" Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-03 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 17:19:44 -0000 Excellent. Thanks, Gonzalo On 29/02/2012 4:37 PM, Leon Portman wrote: > Gonzalo Hi > > I will update the architecture draft accordingly in the next update (hopefully this week). > > Thank you for the comments > > Leon > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Hutton, Andrew > Sent: Wednesday, February 29, 2012 3:55 PM > To: Gonzalo Camarillo; siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-03 > > Hi Gonzalo, > > Thanks for the comments some responses below. > > Regards > Andy > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Gonzalo Camarillo >> Sent: 28 February 2012 11:42 >> To: siprec@ietf.org >> Subject: [siprec] Comments on draft-ietf-siprec-architecture-03 >> >> Hi, >> >> some comments on the architecture draft: >> http://tools.ietf.org/html/draft-ietf-siprec-architecture-03 >> >> All acronyms need to be expanded on their first use. Also, the use of >> acronyms need to be consistent throughout the document. For example, >> in Section 3.1.1 in some cases the acronym appears without its >> expansion, in other cases the expansion appears without the acronym, >> and in other cases both appear together. > > Agree consistency is always a good idea. > >> >> In Section 2 (Definitions), there is a definition of a Recording aware >> UA. For completeness, the text should talk about recording unaware UAs >> as well, either as part of the same definition of as a new term. > > Ok > >> >> Also in that definition: >> s/notify the SIP UA/notify the Recording aware UA/ >> s/all the SIP UA/all the Recording aware UAs/ > > Ok > >> >> The definition of Replicated Media needs to explain its relation with >> the Recording Session (RS). > > Ok. >> >> Section 3.1.1, 4th paragraph: >> s/will need to contain/contains/ >> >> Section 3.1.2, 3rd paragraph. The text could touch upon how a RS can >> know about an endpoint and about the fact that the endpoint will >> establish a session that needs to be recorded at some point. Something >> brief would be enough. > > Ok - I assume when you refer to RS you actually mean SRS. How an SRS knows what and when to record is really out of scope of SIPREC and down to Policy/Configuration in the SRS so that is probably all we can say. > > >> >> Section 3.1.4 talks about the RTCWeb control protocol. The text needs >> to be more explicit because it is not clear what protocol that >> sentence refers to. > > I think it would be best to remove the reference to RTCWeb. > >> >> Section 3.2.1, 3rd bullet. The bullet talks about two possible >> mechanisms. The text should be more clear on that, given that they are >> not just two possible mechanisms out of many. They are the only two >> mechanisms defined in the protocol document, one of which is mandatory >> (i.e., at a MUST level). > > I think this is old text from before we had the protocol draft so we can just remove the options and refer to the protocol draft for the details. > >> >> Section 3.2.2 misses a first bullet like the one in Section 3.2.1, >> about how the URI of the SRC is provisioned. > > Ok. > >> >> Section 3.2.2, 3rd bullet. Why does it say "Possibly"? > > Because it is old text intended to start a discussion and actually we have not firmed up on anything here and leave it to policy at the SRC so we should say so. Normally I think the SRS initiated case is related to persistent recording and so there has been no need to define such a mechanism so far. > >> >> The document could include a bit more text explaining what the >> protocol document defines so that it is easier for readers to >> understand what exactly they will find there. >> >> Cheers, >> >> Gonzalo >> _______________________________________________ >> 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@alum.mit.edu Thu Mar 1 09:50:40 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C2C21E80D0 for ; Thu, 1 Mar 2012 09:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCC0K9xrSfoD for ; Thu, 1 Mar 2012 09:50:39 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id EA27321E80BF for ; Thu, 1 Mar 2012 09:50:35 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta07.westchester.pa.mail.comcast.net with comcast id gHCU1i0041vXlb857Hqc8F; Thu, 01 Mar 2012 17:50:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta17.westchester.pa.mail.comcast.net with comcast id gHqb1i00T07duvL3dHqbeu; Thu, 01 Mar 2012 17:50:36 +0000 Message-ID: <4F4FB6EA.8050203@alum.mit.edu> Date: Thu, 01 Mar 2012 12:50:34 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: john.2.stafford@bt.com References: , <4F4E43D3.8070508@alum.mit.edu> , <387F9047F55E8C42850AD6B3A7A03C6C0E068E45@inba-mail01.sonusnet.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] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 17:50:40 -0000 On 3/1/12 3:53 AM, john.2.stafford@bt.com wrote: > Partha, > > I cant see how using CSG will help with the describing of the streams. > Also I'm not convinced this would be the correct usage of a CSG, as while the calls are associated as they are made by the same person, in terms of sip they are completely unrelated. > I think draft-ietf-metadata could do with an explanation of what relationships a CSG implies. Its your call whether these calls are related in a way that you want to track as a CSG. Clearly there are a number of different reasons you might want to group CSs, and we currently don't provide any attributes to distinguish one reason from another. That is mostly because we didn't want to get into the business of enumerating the possible uses. The solution to that is to add proprietary extension data to the CSG and/or the CSs to identify why they are grouped. Alternatively I would simply treat these as two separate CSs, each with a separate media stream. Thanks, Paul > Rgds > John Stafford | Solution Architect 1 | BT Global Services > ________________________________________ > From: Ravindran, Parthasarathi [pravindran@sonusnet.com] > Sent: 01 March 2012 01:31 > To: Stafford,J,John,JRJ3X C; pkyzivat@alum.mit.edu; siprec@ietf.org > Subject: RE: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream > > John, > > I guess that you are looking for group (CSG) element usage. Person AC sessions has to be grouped under single group. CS AC-B has to be mentioned as one of the session in group and CS AC-D has to be mentioned as another session of the group. Here, user AC is available in both sessions wherein participant (device) A is in session1 and participant (device) C is in session2, it is possible to pass participant name as AC in both sessions and it is perfectly fine. Please let me know whether this approach solves your problem. > > Thanks > Partha > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >> Of john.2.stafford@bt.com >> Sent: Wednesday, February 29, 2012 11:36 PM >> To: pkyzivat@alum.mit.edu; siprec@ietf.org >> Subject: Re: [siprec] How to specify in metadata that multiple CS's are >> being recorded in a single mixed RS m line stream >> >> Paul, >> >> Its one person AC with two handsets both in use at same time, probably >> one to each ear. >> >> Rgds >> John Stafford | Solution Architect 1 | BT Global Services >> ________________________________________ >> From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of >> Paul Kyzivat [pkyzivat@alum.mit.edu] >> Sent: 29 February 2012 15:27 >> To: siprec@ietf.org >> Subject: Re: [siprec] How to specify in metadata that multiple CS's are >> being recorded in a single mixed RS m line stream >> >> On 2/29/12 9:29 AM, john.2.stafford@bt.com wrote: >>> A converse of the "How to specify in metadata that a participants >> stream is being recorded in multiple m line streams" thread: >>> >>> Another of our record configurations is when a turret's handset 1 and >>> handset 2 calls are recorded as a single mixed recorder stream >>> >>> once again a persistent RS will be set up at registration time, in >> this case there will be a single m line. >>> >>> So if represents a record stream, how would the following be >> described in metadata: >>> >>> There are 2 calls, A-B and C-D, both are recorded via a single >> stream. >>> participants A and C are the same person, making two calls on handset >> 1 and handset 2 of their turret. >> >> Just to clarify: >> >> There is one person, call him AC, that has two handsets A and C. >> AC has established one call with B (CS-A-B) and another call with D (CS- >> C-D). >> >> I gather these calls go on in parallel. (Maybe AC is switching back and >> forth taking into one handset of the other. In principal he could put >> one to each ear and use both at the same time.) >> >> Or is this more like a two line phone, with radio buttons to switch >> between the two lines, so that at any given time one is active and the >> other is "on hold"? >> >> I won't even try to respond to the stuff below until I get clarity on >> the above. >> >> Thanks, >> Paul >> >>> The problems I have in describing this in metadata are: >>> 1. I dont know how to show what the participants, as they dont >> recv the 2 call mixed stream. >>> 2. I only have a single stream being recorded which includes 2 CS's, >>> but the element can only have a single session attriibute >>> >>> I can only describe this using >> and. I have not been following the list too >> closely for the past couple of months, is it still the intention to use >> these elements, as I see there is not yet a draft-ietf-metadata-06.txt >> that includes these elements in xml schema and examples. >>> >>> Also I dont know what happens to when using >> associations. >>> >>> Anyway, heres my stab at it, >>> >>> >>> >>> complete >>> >>> >>> >> id="==PARTICIPANT_A==" >>> >>> RamMohan R >>> >>> >>> >> participant="==PARTICIPANT_A==" >>> session="====SESSION_ONE====="> >>> 2010-12-16T23:41:07Z> time> >>> TBD >>> >>> >> participant="==PARTICIPANT_A==" >>> stream ="i1Pz3to5hGk8fuXl+PbwCw=="> >>> 2010-12-16T23:41:07Z> time> >>> >>> >>> >> id="==PARTICIPANT_B==" >>> >>> Paul Kyzivat >>> >>> >>> >> participant="==PARTICIPANT_B==" >>> session="====SESSION_ONE====="> >>> 2010-12-16T23:41:07Z> time> >>> TBD >>> >>> >> participant="==PARTICIPANT_B==" >>> stream ="i1Pz3to5hGk8fuXl+PbwCw=="> >>> 2010-12-16T23:41:07Z> time> >>> >>> >>> >>> >>> >>> >> id="==PARTICIPANT_C==" >>> >>> RamMohan R >>> >>> >>> >> participant="==PARTICIPANT_C==" >>> session="====SESSION_TWO====="> >>> 2010-12-16T22:02:04Z> time> >>> TBD >>> >>> >> participant="==PARTICIPANT_C==" >>> stream ="i1Pz3to5hGk8fuXl+PbwCw=="> >>> 2010-12-16T22:02:04Z> time> >>> >>> >>> >> id="==PARTICIPANT_D==" >>> >>> Andrew >> Hutton >>> >>> >>> >> participant="==PARTICIPANT_D==" >>> session="====SESSION_TWO====="> >>> 2010-12-16T22:02:04Z> time> >>> TBD >>> >>> >> participant="==PARTICIPANT_D==" >>> stream ="i1Pz3to5hGk8fuXl+PbwCw=="> >>> 2010-12-16T22:02:04Z> time> >>> >>> >>> >> >>> >>> >>> >>> >>> Rgds >>> John Stafford | Solution Architect 1 | BT Global Services >>> _______________________________________________ >>> 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 Fri Mar 2 09:20:23 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02EC21F863E for ; Fri, 2 Mar 2012 09:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.132 X-Spam-Level: X-Spam-Status: No, score=-9.132 tagged_above=-999 required=5 tests=[AWL=1.467, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mHdiHaiSMFT for ; Fri, 2 Mar 2012 09:20:22 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA4521F863B for ; Fri, 2 Mar 2012 09:20:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2034; q=dns/txt; s=iport; t=1330708822; x=1331918422; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=df1GxRR0mGI8W7ddgg1rinmqNOYKvIOlmcul6jSoiRc=; b=ldhY1VlMwSBDggj5zQ9dAFx045ffvDx3oK8ms5ksNArGuETu4CIg/dcI eohJpjA+YYO8Q6BPm1yZ1VTSN+34HwY93GSHmhtwtv+fKM75tANCFWZ08 Od9RAO+c7keM9rKc6fCejsKqpDvBqbs5oG2vuNJNY6EZqU9bVJ6DzoqoW o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHMAUU+rRDoG/2dsb2JhbABDtEWBB4F9AQEBBBIBHQoxDgwEAgEIEQQBAQsGFwEGASAlCQgBAQQBEggah2MBoQIBlx6JIIVhYwSIUIkRjnuHeA X-IronPort-AV: E=Sophos;i="4.73,518,1325462400"; d="scan'208";a="31616635" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 02 Mar 2012 17:20:21 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q22HKMSh004824; Fri, 2 Mar 2012 17:20:22 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); Fri, 2 Mar 2012 09:20:22 -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, 2 Mar 2012 09:20:21 -0800 Message-ID: In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312945D5928@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIPREC Protocol draft and merge of draft-eckel-siprec-rtp-rec-03 Thread-Index: Acz3vuHI0BO7jot3SmO9nq+Y5OInxAA1wqOw References: <101C6067BEC68246B0C3F6843BCCC1E312945D5928@MCHP058A.global-ad.net> From: "Charles Eckel (eckelcu)" To: "Hutton, Andrew" , "Henry Lum" , X-OriginalArrivalTime: 02 Mar 2012 17:20:22.0071 (UTC) FILETIME=[BFA26470:01CCF898] Cc: siprec@ietf.org Subject: Re: [siprec] SIPREC Protocol draft and merge of draft-eckel-siprec-rtp-rec-03 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 02 Mar 2012 17:20:23 -0000 Hi Andy, Based on the comments and discussion at IETF 83, I think the following additions to the draft would be beneficial: 1) SSRC based multiplexing Explicitly mention multiplexing using SSRC, not RTP session multiplexing, and illustrate how a two party call may be recorded by a B2BUA acting as an SRC, using either multiple m-lines or a single m-line toward the SRS. Note, there was some discussion regarding two separate calls being recorded in a single RS with single m-line? I do not think we need to dive into this, but we can if others think it is important to do so. 2) Split personality SRC draft-eckel-siprec-rtp-rec-03 describes the RTP/RTCP handling expected by SIPREC SRCs and SRSs, as well as SIPREC aware UAs and unaware UAs. In addition to the models stated currently, there is also a model in which the SRC acts as an RTP/RTCP translator toward the UAs within the CS(s), and as an RTP/RTCP endpoint toward the SRS for the corresponding RS. I have not gotten my head around this model completely, but I think it may be a useful exercise to discuss and perhaps add corresponding text to the draft. Cheers, Charles > -----Original Message----- > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > Sent: Thursday, March 01, 2012 7:21 AM > To: Charles Eckel (eckelcu); Henry Lum; brian.rosen@gmail.com > Cc: siprec@ietf.org > Subject: SIPREC Protocol draft and merge of draft-eckel-siprec-rtp-rec- > 03 >=20 > Hi All, >=20 > We still have a place holder in draft-ietf-siprec-protocol for > including text from draft-eckel-siprec-rtp-rec-03. >=20 > What is holding is up with this do we need more review from AVT experts > or is it something else? >=20 > I see from the Taipei minutes that "section 4.3 needs more text about > various usages of RTP by mixers/translators". >=20 > Charles, can you initiate discussion on the list to move this forward > or let me know what other action we need to take. >=20 > Regards > Andy (SIPREC Co-Chair). From john.2.stafford@bt.com Mon Mar 5 08:45:50 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36AA521F878B for ; Mon, 5 Mar 2012 08:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.986 X-Spam-Level: X-Spam-Status: No, score=-2.986 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gP1yq9q21XBQ for ; Mon, 5 Mar 2012 08:45:49 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id BBB2C21F8771 for ; Mon, 5 Mar 2012 08:45:48 -0800 (PST) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 5 Mar 2012 16:45:47 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.101]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Mon, 5 Mar 2012 16:45:46 +0000 From: To: Date: Mon, 5 Mar 2012 16:45:46 +0000 Thread-Topic: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream Thread-Index: Acz3087e0kyzl+75SbG0/+5w54pxqgACI5aS Message-ID: References: , <4F4E43D3.8070508@alum.mit.edu> , <387F9047F55E8C42850AD6B3A7A03C6C0E068E45@inba-mail01.sonusnet.com> , <4F4FB6EA.8050203@alum.mit.edu> In-Reply-To: <4F4FB6EA.8050203@alum.mit.edu> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: siprec@ietf.org Subject: Re: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 05 Mar 2012 16:45:50 -0000 Ok, CSG is not a concern. What I wanted clarified was how metadata s and would look when you = have two simultaneous calls on an endpoint and both calls are mixed into a = single recorder stream. If represents the mixed stream of two calls going to the recorder,= then how can a participant have a that references that stream,=20 as a participant does NOT recv the mixed stream. Rgds John Stafford | Solution Architect 1 | BT Global Services=20 ________________________________________ From: Paul Kyzivat [pkyzivat@alum.mit.edu] Sent: 01 March 2012 17:50 To: Stafford,J,John,JRJ3X C Cc: pravindran@sonusnet.com; siprec@ietf.org Subject: Re: [siprec] How to specify in metadata that multiple CS's are bei= ng recorded in a single mixed RS m line stream On 3/1/12 3:53 AM, john.2.stafford@bt.com wrote: > Partha, > > I cant see how using CSG will help with the describing of the streams. > Also I'm not convinced this would be the correct usage of a CSG, as while= the calls are associated as they are made by the same person, in terms of = sip they are completely unrelated. > I think draft-ietf-metadata could do with an explanation of what relation= ships a CSG implies. Its your call whether these calls are related in a way that you want to track as a CSG. Clearly there are a number of different reasons you might want to group CSs, and we currently don't provide any attributes to distinguish one reason from another. That is mostly because we didn't want to get into the business of enumerating the possible uses. The solution to that is to add proprietary extension data to the CSG and/or the CSs to identify why they are grouped. Alternatively I would simply treat these as two separate CSs, each with a separate media stream. Thanks, Paul > Rgds > John Stafford | Solution Architect 1 | BT Global Services > ________________________________________ > From: Ravindran, Parthasarathi [pravindran@sonusnet.com] > Sent: 01 March 2012 01:31 > To: Stafford,J,John,JRJ3X C; pkyzivat@alum.mit.edu; siprec@ietf.org > Subject: RE: [siprec] How to specify in metadata that multiple CS's are b= eing recorded in a single mixed RS m line stream > > John, > > I guess that you are looking for group (CSG) element usage. Person AC ses= sions has to be grouped under single group. CS AC-B has to be mentioned as = one of the session in group and CS AC-D has to be mentioned as another sess= ion of the group. Here, user AC is available in both sessions wherein parti= cipant (device) A is in session1 and participant (device) C is in session2,= it is possible to pass participant name as AC in both sessions and it is p= erfectly fine. Please let me know whether this approach solves your problem= . > > Thanks > Partha > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >> Of john.2.stafford@bt.com >> Sent: Wednesday, February 29, 2012 11:36 PM >> To: pkyzivat@alum.mit.edu; siprec@ietf.org >> Subject: Re: [siprec] How to specify in metadata that multiple CS's are >> being recorded in a single mixed RS m line stream >> >> Paul, >> >> Its one person AC with two handsets both in use at same time, probably >> one to each ear. >> >> Rgds >> John Stafford | Solution Architect 1 | BT Global Services >> ________________________________________ >> From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of >> Paul Kyzivat [pkyzivat@alum.mit.edu] >> Sent: 29 February 2012 15:27 >> To: siprec@ietf.org >> Subject: Re: [siprec] How to specify in metadata that multiple CS's are >> being recorded in a single mixed RS m line stream >> >> On 2/29/12 9:29 AM, john.2.stafford@bt.com wrote: >>> A converse of the "How to specify in metadata that a participants >> stream is being recorded in multiple m line streams" thread: >>> >>> Another of our record configurations is when a turret's handset 1 and >>> handset 2 calls are recorded as a single mixed recorder stream >>> >>> once again a persistent RS will be set up at registration time, in >> this case there will be a single m line. >>> >>> So if represents a record stream, how would the following be >> described in metadata: >>> >>> There are 2 calls, A-B and C-D, both are recorded via a single >> stream. >>> participants A and C are the same person, making two calls on handset >> 1 and handset 2 of their turret. >> >> Just to clarify: >> >> There is one person, call him AC, that has two handsets A and C. >> AC has established one call with B (CS-A-B) and another call with D (CS- >> C-D). >> >> I gather these calls go on in parallel. (Maybe AC is switching back and >> forth taking into one handset of the other. In principal he could put >> one to each ear and use both at the same time.) >> >> Or is this more like a two line phone, with radio buttons to switch >> between the two lines, so that at any given time one is active and the >> other is "on hold"? >> >> I won't even try to respond to the stuff below until I get clarity on >> the above. >> >> Thanks, >> Paul >> >>> The problems I have in describing this in metadata are: >>> 1. I dont know how to show what the participants, as they dont >> recv the 2 call mixed stream. >>> 2. I only have a single stream being recorded which includes 2 CS's, >>> but the element can only have a single session attriibute >>> >>> I can only describe this using >> and. I have not been following the list too >> closely for the past couple of months, is it still the intention to use >> these elements, as I see there is not yet a draft-ietf-metadata-06.txt >> that includes these elements in xml schema and examples. >>> >>> Also I dont know what happens to when using >> associations. >>> >>> Anyway, heres my stab at it, >>> >>> >>> >>> complete >>> >>> >>> >> id=3D"=3D=3DPARTICIPANT_A=3D=3D" >>> >>> RamMohan R >>> >>> >>> >> participant=3D"=3D=3DPARTICIPANT_A=3D=3D" >>> session=3D"=3D=3D=3D=3DSESSION_ONE=3D=3D=3D=3D=3D"> >>> 2010-12-16T23:41:07Z> time> >>> TBD >>> >>> >> participant=3D"=3D=3DPARTICIPANT_A=3D=3D" >>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> >>> 2010-12-16T23:41:07Z> time> >>> >>> >>> >> id=3D"=3D=3DPARTICIPANT_B=3D=3D" >>> >>> Paul Kyzivat >>> >>> >>> >> participant=3D"=3D=3DPARTICIPANT_B=3D=3D" >>> session=3D"=3D=3D=3D=3DSESSION_ONE=3D=3D=3D=3D=3D"> >>> 2010-12-16T23:41:07Z> time> >>> TBD >>> >>> >> participant=3D"=3D=3DPARTICIPANT_B=3D=3D" >>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> >>> 2010-12-16T23:41:07Z> time> >>> >>> >>> >>> >>> >>> >> id=3D"=3D=3DPARTICIPANT_C=3D=3D" >>> >>> RamMohan R >>> >>> >>> >> participant=3D"=3D=3DPARTICIPANT_C=3D=3D" >>> session=3D"=3D=3D=3D=3DSESSION_TWO=3D=3D=3D=3D=3D"> >>> 2010-12-16T22:02:04Z> time> >>> TBD >>> >>> >> participant=3D"=3D=3DPARTICIPANT_C=3D=3D" >>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> >>> 2010-12-16T22:02:04Z> time> >>> >>> >>> >> id=3D"=3D=3DPARTICIPANT_D=3D=3D" >>> >>> Andrew >> Hutton >>> >>> >>> >> participant=3D"=3D=3DPARTICIPANT_D=3D=3D" >>> session=3D"=3D=3D=3D=3DSESSION_TWO=3D=3D=3D=3D=3D"> >>> 2010-12-16T22:02:04Z> time> >>> TBD >>> >>> >> participant=3D"=3D=3DPARTICIPANT_D=3D=3D" >>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> >>> 2010-12-16T22:02:04Z> time> >>> >>> >>> >> >>> >>> >>> >>> >>> Rgds >>> John Stafford | Solution Architect 1 | BT Global Services >>> _______________________________________________ >>> 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@alum.mit.edu Mon Mar 5 14:32:40 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0630221E804E for ; Mon, 5 Mar 2012 14:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xw6T2JusWSB6 for ; Mon, 5 Mar 2012 14:32:39 -0800 (PST) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id 83C6F21E8059 for ; Mon, 5 Mar 2012 14:32:36 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta14.westchester.pa.mail.comcast.net with comcast id hxyH1i0031ap0As5EyYdHQ; Mon, 05 Mar 2012 22:32:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta22.westchester.pa.mail.comcast.net with comcast id hyYc1i02g07duvL3iyYcGG; Mon, 05 Mar 2012 22:32:36 +0000 Message-ID: <4F553F1C.9070400@alum.mit.edu> Date: Mon, 05 Mar 2012 17:33:00 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: john.2.stafford@bt.com References: , <4F4E43D3.8070508@alum.mit.edu> , <387F9047F55E8C42850AD6B3A7A03C6C0E068E45@inba-mail01.sonusnet.com> , <4F4FB6EA.8050203@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 05 Mar 2012 22:32:40 -0000 On 3/5/12 11:45 AM, john.2.stafford@bt.com wrote: > Ok, CSG is not a concern. > > What I wanted clarified was how metadatas and would look when you have two simultaneous calls on an endpoint and both calls are mixed into a single recorder stream. > > If represents the mixed stream of two calls going to the recorder, then how can a participant have a that references that stream, > as a participant does NOT recv the mixed stream. I don't understand how it makes sense to mix the media for two distinct calls. Or do you mean that you want to send them both over a single RTP session, distinguished by SSRC or CSRC? Thanks, Paul > > Rgds > John Stafford | Solution Architect 1 | BT Global Services > ________________________________________ > From: Paul Kyzivat [pkyzivat@alum.mit.edu] > Sent: 01 March 2012 17:50 > To: Stafford,J,John,JRJ3X C > Cc: pravindran@sonusnet.com; siprec@ietf.org > Subject: Re: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream > > On 3/1/12 3:53 AM, john.2.stafford@bt.com wrote: >> Partha, >> >> I cant see how using CSG will help with the describing of the streams. >> Also I'm not convinced this would be the correct usage of a CSG, as while the calls are associated as they are made by the same person, in terms of sip they are completely unrelated. >> I think draft-ietf-metadata could do with an explanation of what relationships a CSG implies. > > Its your call whether these calls are related in a way that you want to > track as a CSG. > > Clearly there are a number of different reasons you might want to group > CSs, and we currently don't provide any attributes to distinguish one > reason from another. That is mostly because we didn't want to get into > the business of enumerating the possible uses. The solution to that is > to add proprietary extension data to the CSG and/or the CSs to identify > why they are grouped. > > Alternatively I would simply treat these as two separate CSs, each with > a separate media stream. > > Thanks, > Paul > >> Rgds >> John Stafford | Solution Architect 1 | BT Global Services >> ________________________________________ >> From: Ravindran, Parthasarathi [pravindran@sonusnet.com] >> Sent: 01 March 2012 01:31 >> To: Stafford,J,John,JRJ3X C; pkyzivat@alum.mit.edu; siprec@ietf.org >> Subject: RE: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream >> >> John, >> >> I guess that you are looking for group (CSG) element usage. Person AC sessions has to be grouped under single group. CS AC-B has to be mentioned as one of the session in group and CS AC-D has to be mentioned as another session of the group. Here, user AC is available in both sessions wherein participant (device) A is in session1 and participant (device) C is in session2, it is possible to pass participant name as AC in both sessions and it is perfectly fine. Please let me know whether this approach solves your problem. >> >> Thanks >> Partha >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >>> Of john.2.stafford@bt.com >>> Sent: Wednesday, February 29, 2012 11:36 PM >>> To: pkyzivat@alum.mit.edu; siprec@ietf.org >>> Subject: Re: [siprec] How to specify in metadata that multiple CS's are >>> being recorded in a single mixed RS m line stream >>> >>> Paul, >>> >>> Its one person AC with two handsets both in use at same time, probably >>> one to each ear. >>> >>> Rgds >>> John Stafford | Solution Architect 1 | BT Global Services >>> ________________________________________ >>> From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of >>> Paul Kyzivat [pkyzivat@alum.mit.edu] >>> Sent: 29 February 2012 15:27 >>> To: siprec@ietf.org >>> Subject: Re: [siprec] How to specify in metadata that multiple CS's are >>> being recorded in a single mixed RS m line stream >>> >>> On 2/29/12 9:29 AM, john.2.stafford@bt.com wrote: >>>> A converse of the "How to specify in metadata that a participants >>> stream is being recorded in multiple m line streams" thread: >>>> >>>> Another of our record configurations is when a turret's handset 1 and >>>> handset 2 calls are recorded as a single mixed recorder stream >>>> >>>> once again a persistent RS will be set up at registration time, in >>> this case there will be a single m line. >>>> >>>> So if represents a record stream, how would the following be >>> described in metadata: >>>> >>>> There are 2 calls, A-B and C-D, both are recorded via a single >>> stream. >>>> participants A and C are the same person, making two calls on handset >>> 1 and handset 2 of their turret. >>> >>> Just to clarify: >>> >>> There is one person, call him AC, that has two handsets A and C. >>> AC has established one call with B (CS-A-B) and another call with D (CS- >>> C-D). >>> >>> I gather these calls go on in parallel. (Maybe AC is switching back and >>> forth taking into one handset of the other. In principal he could put >>> one to each ear and use both at the same time.) >>> >>> Or is this more like a two line phone, with radio buttons to switch >>> between the two lines, so that at any given time one is active and the >>> other is "on hold"? >>> >>> I won't even try to respond to the stuff below until I get clarity on >>> the above. >>> >>> Thanks, >>> Paul >>> >>>> The problems I have in describing this in metadata are: >>>> 1. I dont know how to show what the participants, as they dont >>> recv the 2 call mixed stream. >>>> 2. I only have a single stream being recorded which includes 2 CS's, >>>> but the element can only have a single session attriibute >>>> >>>> I can only describe this using >>> and. I have not been following the list too >>> closely for the past couple of months, is it still the intention to use >>> these elements, as I see there is not yet a draft-ietf-metadata-06.txt >>> that includes these elements in xml schema and examples. >>>> >>>> Also I dont know what happens to when using >>> associations. >>>> >>>> Anyway, heres my stab at it, >>>> >>>> >>>> >>>> complete >>>> >>>> >>>> >>> id="==PARTICIPANT_A==" >>>> >>>> RamMohan R >>>> >>>> >>>> >>> participant="==PARTICIPANT_A==" >>>> session="====SESSION_ONE====="> >>>> 2010-12-16T23:41:07Z>> time> >>>> TBD >>>> >>>> >>> participant="==PARTICIPANT_A==" >>>> stream ="i1Pz3to5hGk8fuXl+PbwCw=="> >>>> 2010-12-16T23:41:07Z>> time> >>>> >>>> >>>> >>> id="==PARTICIPANT_B==" >>>> >>>> Paul Kyzivat >>>> >>>> >>>> >>> participant="==PARTICIPANT_B==" >>>> session="====SESSION_ONE====="> >>>> 2010-12-16T23:41:07Z>> time> >>>> TBD >>>> >>>> >>> participant="==PARTICIPANT_B==" >>>> stream ="i1Pz3to5hGk8fuXl+PbwCw=="> >>>> 2010-12-16T23:41:07Z>> time> >>>> >>>> >>>> >>>> >>>> >>>> >>> id="==PARTICIPANT_C==" >>>> >>>> RamMohan R >>>> >>>> >>>> >>> participant="==PARTICIPANT_C==" >>>> session="====SESSION_TWO====="> >>>> 2010-12-16T22:02:04Z>> time> >>>> TBD >>>> >>>> >>> participant="==PARTICIPANT_C==" >>>> stream ="i1Pz3to5hGk8fuXl+PbwCw=="> >>>> 2010-12-16T22:02:04Z>> time> >>>> >>>> >>>> >>> id="==PARTICIPANT_D==" >>>> >>>> Andrew >>> Hutton >>>> >>>> >>>> >>> participant="==PARTICIPANT_D==" >>>> session="====SESSION_TWO====="> >>>> 2010-12-16T22:02:04Z>> time> >>>> TBD >>>> >>>> >>> participant="==PARTICIPANT_D==" >>>> stream ="i1Pz3to5hGk8fuXl+PbwCw=="> >>>> 2010-12-16T22:02:04Z>> time> >>>> >>>> >>>> >>> >>>> >>>> >>>> >>>> >>>> Rgds >>>> John Stafford | Solution Architect 1 | BT Global Services >>>> _______________________________________________ >>>> 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 bchrustie@securelogix.com Wed Mar 7 13:43:52 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E472C11E80B5 for ; Wed, 7 Mar 2012 13:43:52 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkAGyderjJSN for ; Wed, 7 Mar 2012 13:43:52 -0800 (PST) Received: from hub026-CA-2.exch026.serverdata.net (hub026-ca-2.exch026.serverdata.net [64.78.56.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7E711E80B2 for ; Wed, 7 Mar 2012 13:43:51 -0800 (PST) Received: from MBX026-W1-CA-7.exch026.domain.local ([10.254.14.57]) by HUB026-CA-2.exch026.domain.local ([10.254.14.33]) with mapi id 14.01.0355.002; Wed, 7 Mar 2012 13:43:42 -0800 From: Bruce Chrustie To: "siprec@ietf.org" Thread-Topic: Use Case 10 & 12 Thread-Index: Acz8qEKzd+3W9yEPSQu279GFn3tLGg== Date: Wed, 7 Mar 2012 21:43:41 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [207.193.132.100] Content-Type: multipart/alternative; boundary="_000_F0EE3CE866B8454295BD186058369DDAEF645Bmbx026w1ca7exch02_" MIME-Version: 1.0 Subject: [siprec] Use Case 10 & 12 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 07 Mar 2012 21:45:22 -0000 --_000_F0EE3CE866B8454295BD186058369DDAEF645Bmbx026w1ca7exch02_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi gang, Looking at these use cases in the RFC I see the need for the SRC to termina= te a CS based upon an autonomous activities within the SRS. I see a couple = options on how this would happen: -SRS terminates the RS and the SRC has an implementation to terminate the C= S in such instances. The struggle I have with this is that it is vendor dep= endent on if/how it is implemented. Especially relevant to #12. There is no= thing I see within the drafts that would force a SRC to drop a CS because a= RS was dropped. It would not make sense to do so either without it being e= xplicitly requested. -SRS sends BYE with metadata to terminate the CS by the SRC. Not able to to= day. Can you enlighten me with some signaling scenarios on what the initial solu= tions were to these two scenarios? My preference is there is explicit capab= ility within protocol & metadata that a CS be terminated when a SRS sends a= BYE (or some variation). Bruce, --_000_F0EE3CE866B8454295BD186058369DDAEF645Bmbx026w1ca7exch02_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi gang,

 

Looking at these use cases in the RFC I see the need= for the SRC to terminate a CS based upon an autonomous activities within t= he SRS. I see a couple options on how this would happen:

 

-SRS terminates the RS and the SRC has an implementa= tion to terminate the CS in such instances. The struggle I have with this i= s that it is vendor dependent on if/how it is implemented. Especially relev= ant to #12. There is nothing I see within the drafts that would force a SRC to drop a CS because a RS was dro= pped. It would not make sense to do so either without it being explicitly r= equested.

 

-SRS sends BYE with metadata to terminate the CS by = the SRC. Not able to today.

 

Can you enlighten me with some signaling scenarios o= n what the initial solutions were to these two scenarios? My preference is = there is explicit capability within protocol & metadata that a CS be te= rminated when a SRS sends a BYE (or some variation).

 

Bruce,

--_000_F0EE3CE866B8454295BD186058369DDAEF645Bmbx026w1ca7exch02_-- From pravindran@sonusnet.com Wed Mar 7 22:24:58 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50EAC21F8551 for ; Wed, 7 Mar 2012 22:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4St1qFZ+95J0 for ; Wed, 7 Mar 2012 22:24:56 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD6021F847A for ; Wed, 7 Mar 2012 22:24:49 -0800 (PST) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q286Pb73021533; Thu, 8 Mar 2012 01:25:37 -0500 Received: from USMA-EX-HUB2.sonusnet.com ([66.203.90.17]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 01:24:47 -0500 Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 8 Mar 2012 01:24:53 -0500 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Thu, 8 Mar 2012 11:54:43 +0530 From: "Ravindran, Parthasarathi" To: Bruce Chrustie , "siprec@ietf.org" Thread-Topic: Use Case 10 & 12 Thread-Index: Acz8qEKzd+3W9yEPSQu279GFn3tLGgASkumA Date: Thu, 8 Mar 2012 06:24:42 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E1F4EB4@inba-mail01.sonusnet.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.67] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C0E1F4EB4inbamail01sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 08 Mar 2012 06:24:47.0432 (UTC) FILETIME=[28D74C80:01CCFCF4] Subject: Re: [siprec] Use Case 10 & 12 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 06:24:58 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C0E1F4EB4inbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bruce, CS termination in SRC based on RS termination from SRS is a policy decision= in SRC and It is clear in usecase 10(High availability) as follows: o The Communication Session must be terminated (or suitable notification given to parties) in the event of a recording failure. In case of recording failure, SRC may indicate the notification to the part= ies using "record" attribute in draft-ietf-siprec-protocol or send BYE towa= rds both parties. For usecase #12, Real-time analytics may be employed for automatic intervention (stopping interaction or alerting) if for example, a trader is not following regulations. In case of real-time analytics, SRC application has to be terminate CS or a= lert the user about failure to record in case of RS is terminated. Thanks Partha From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Bruce Chrustie Sent: Thursday, March 08, 2012 3:14 AM To: siprec@ietf.org Subject: [siprec] Use Case 10 & 12 Hi gang, Looking at these use cases in the RFC I see the need for the SRC to termina= te a CS based upon an autonomous activities within the SRS. I see a couple = options on how this would happen: -SRS terminates the RS and the SRC has an implementation to terminate the C= S in such instances. The struggle I have with this is that it is vendor dep= endent on if/how it is implemented. Especially relevant to #12. There is no= thing I see within the drafts that would force a SRC to drop a CS because a= RS was dropped. It would not make sense to do so either without it being e= xplicitly requested. -SRS sends BYE with metadata to terminate the CS by the SRC. Not able to to= day. Can you enlighten me with some signaling scenarios on what the initial solu= tions were to these two scenarios? My preference is there is explicit capab= ility within protocol & metadata that a CS be terminated when a SRS sends a= BYE (or some variation). Bruce, --_000_387F9047F55E8C42850AD6B3A7A03C6C0E1F4EB4inbamail01sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bruce,

 

CS termination in SRC = based on RS termination from SRS is a policy decision in SRC and  It i= s clear in usecase 10(High availability) as follows:

 

  = ;    o  The Communication Session must be terminated (o= r suitable

  = ;       notification given to parties) in the= event of a recording

  = ;       failure.

 =

In case of recording f= ailure, SRC may indicate the notification to the parties using “recor= d” attribute in draft-ietf-siprec-protocol or send BYE towards both p= arties.

 

For usecase #12,<= /o:p>

 

Real-time analytics may be employed for automatic intervention (s=
topping
   interaction or alerting) if for example, a trader is=
 not following
   regulations.
 

In case of real-time a= nalytics, SRC application has to be terminate CS or alert the user about fa= ilure to record in case of RS is terminated.

 

Thanks

Partha

 

From: siprec-b= ounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Bruce Chrustie
Sent: Thursday, March 08, 2012 3:14 AM
To: siprec@ietf.org
Subject: [siprec] Use Case 10 & 12

 

Hi gang,

 

Looking at these use cases in the RFC I see the need= for the SRC to terminate a CS based upon an autonomous activities within t= he SRS. I see a couple options on how this would happen:

 

-SRS terminates the RS and the SRC has an implementa= tion to terminate the CS in such instances. The struggle I have with this i= s that it is vendor dependent on if/how it is implemented. Especially relev= ant to #12. There is nothing I see within the drafts that would force a SRC to drop a CS because a RS was dro= pped. It would not make sense to do so either without it being explicitly r= equested.

 

-SRS sends BYE with metadata to terminate the CS by = the SRC. Not able to today.

 

Can you enlighten me with some signaling scenarios o= n what the initial solutions were to these two scenarios? My preference is = there is explicit capability within protocol & metadata that a CS be te= rminated when a SRS sends a BYE (or some variation).

 

Bruce,

--_000_387F9047F55E8C42850AD6B3A7A03C6C0E1F4EB4inbamail01sonus_-- From bchrustie@securelogix.com Thu Mar 8 07:26:07 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3149421F8507 for ; Thu, 8 Mar 2012 07:26:07 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pU4BTL8j2Uj7 for ; Thu, 8 Mar 2012 07:26:04 -0800 (PST) Received: from hub026-CA-1.exch026.serverdata.net (hub026-ca-1.exch026.serverdata.net [64.78.56.36]) by ietfa.amsl.com (Postfix) with ESMTP id E470221F856F for ; Thu, 8 Mar 2012 07:26:04 -0800 (PST) Received: from MBX026-W1-CA-7.exch026.domain.local ([10.254.14.57]) by HUB026-CA-1.exch026.domain.local ([10.254.14.30]) with mapi id 14.01.0355.002; Thu, 8 Mar 2012 07:26:04 -0800 From: Bruce Chrustie To: "siprec@ietf.org" Thread-Topic: Use Case 10 & 12 Thread-Index: Acz8qEKzd+3W9yEPSQu279GFn3tLGgASkumAABMYvFA= Date: Thu, 8 Mar 2012 15:26:03 +0000 Message-ID: References: <387F9047F55E8C42850AD6B3A7A03C6C0E1F4EB4@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E1F4EB4@inba-mail01.sonusnet.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [207.193.132.100] Content-Type: multipart/alternative; boundary="_000_F0EE3CE866B8454295BD186058369DDAEF6687mbx026w1ca7exch02_" MIME-Version: 1.0 Subject: Re: [siprec] Use Case 10 & 12 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 15:26:07 -0000 --_000_F0EE3CE866B8454295BD186058369DDAEF6687mbx026w1ca7exch02_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Partha, We agree on the action the SRC should take. My issue is that there is nothi= ng in draft-ietf-siprec-protocol-02 that calls this behavior out explicitly= in section 5 & 6 and it needs to be there. Further, there are two scenarios: 'financial bank' and 'webstore callcenter= ' 'financial bank' is mandated to record all calls, and if the RS drops the c= orresponding CS should be dropped 'webstore callcenter' records for informational purposes a fraction of thei= r calls. Having a RS fail would not dictate a CS termination. This variability in what happens in the SRC right now is ambiguous and I th= ink it needs to be addressed explicitly both in addition to callflows betwe= en the SRS to SRC when it wants a CS terminated as well as SRC behavior upo= n a RS termination during an active CS. Bruce From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] Sent: Thursday, March 08, 2012 1:25 AM To: Bruce Chrustie; siprec@ietf.org Subject: RE: Use Case 10 & 12 Bruce, CS termination in SRC based on RS termination from SRS is a policy decision= in SRC and It is clear in usecase 10(High availability) as follows: o The Communication Session must be terminated (or suitable notification given to parties) in the event of a recording failure. In case of recording failure, SRC may indicate the notification to the part= ies using "record" attribute in draft-ietf-siprec-protocol or send BYE towa= rds both parties. For usecase #12, Real-time analytics may be employed for automatic intervention (stopping interaction or alerting) if for example, a trader is not following regulations. In case of real-time analytics, SRC application has to be terminate CS or a= lert the user about failure to record in case of RS is terminated. Thanks Partha From: siprec-bounces@ietf.org [mailto:sipre= c-bounces@ietf.org] On Behalf Of B= ruce Chrustie Sent: Thursday, March 08, 2012 3:14 AM To: siprec@ietf.org Subject: [siprec] Use Case 10 & 12 Hi gang, Looking at these use cases in the RFC I see the need for the SRC to termina= te a CS based upon an autonomous activities within the SRS. I see a couple = options on how this would happen: -SRS terminates the RS and the SRC has an implementation to terminate the C= S in such instances. The struggle I have with this is that it is vendor dep= endent on if/how it is implemented. Especially relevant to #12. There is no= thing I see within the drafts that would force a SRC to drop a CS because a= RS was dropped. It would not make sense to do so either without it being e= xplicitly requested. -SRS sends BYE with metadata to terminate the CS by the SRC. Not able to to= day. Can you enlighten me with some signaling scenarios on what the initial solu= tions were to these two scenarios? My preference is there is explicit capab= ility within protocol & metadata that a CS be terminated when a SRS sends a= BYE (or some variation). Bruce, --_000_F0EE3CE866B8454295BD186058369DDAEF6687mbx026w1ca7exch02_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Partha,<= /span>

 

We agree on the action= the SRC should take. My issue is that there is nothing in draft-ietf-sipre= c-protocol-02 that calls this behavior out explicitly in section 5 & 6 = and it needs to be there.

 

Further, there are two= scenarios: ‘financial bank’ and ‘webstore callcenterR= 17;

 

‘financial bank&= #8217; is mandated to record all calls, and if the RS drops the correspondi= ng CS should be dropped

 

‘webstore callce= nter’ records for informational purposes a fraction of their calls. H= aving a RS fail would not dictate a CS termination.

 

This variability in wh= at happens in the SRC right now is ambiguous and I think it needs to be add= ressed explicitly both in addition to callflows between the SRS to SRC when= it wants a CS terminated as well as SRC behavior upon a RS termination during an active CS.<= /p>

 

Bruce

 

 

From: Ravindra= n, Parthasarathi [mailto:pravindran@sonusnet.com]
Sent: Thursday, March 08, 2012 1:25 AM
To: Bruce Chrustie; siprec@ietf.org
Subject: RE: Use Case 10 & 12

 

Bruce,

 

CS termination in SRC = based on RS termination from SRS is a policy decision in SRC and  It i= s clear in usecase 10(High availability) as follows:

 

  = ;    o  The Communication Session must be terminated (o= r suitable

  = ;       notification given to parties) in the= event of a recording

  = ;       failure.

 =

In case of recording f= ailure, SRC may indicate the notification to the parties using “recor= d” attribute in draft-ietf-siprec-protocol or send BYE towards both p= arties.

 

For usecase #12,<= /o:p>

 

Real-time analytics may be employed for automatic intervention (s=
topping
   interaction or alerting) if for example, a trader is=
 not following
   regulations.
 

In case of real-time a= nalytics, SRC application has to be terminate CS or alert the user about fa= ilure to record in case of RS is terminated.

 

Thanks

Partha

 

From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Bruce Chrustie
Sent: Thursday, March 08, 2012 3:14 AM
To: siprec@ietf.org
Subject: [siprec] Use Case 10 & 12

 

Hi gang,

 

Looking at these use cases in the RFC I see the need= for the SRC to terminate a CS based upon an autonomous activities within t= he SRS. I see a couple options on how this would happen:

 

-SRS terminates the RS and the SRC has an implementa= tion to terminate the CS in such instances. The struggle I have with this i= s that it is vendor dependent on if/how it is implemented. Especially relev= ant to #12. There is nothing I see within the drafts that would force a SRC to drop a CS because a RS was dro= pped. It would not make sense to do so either without it being explicitly r= equested.

 

-SRS sends BYE with metadata to terminate the CS by = the SRC. Not able to today.

 

Can you enlighten me with some signaling scenarios o= n what the initial solutions were to these two scenarios? My preference is = there is explicit capability within protocol & metadata that a CS be te= rminated when a SRS sends a BYE (or some variation).

 

Bruce,

--_000_F0EE3CE866B8454295BD186058369DDAEF6687mbx026w1ca7exch02_-- From Henry.Lum@genesyslab.com Thu Mar 8 11:48:13 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62CBB21F8534 for ; Thu, 8 Mar 2012 11:48:13 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9PyvqDeu-Mf for ; Thu, 8 Mar 2012 11:48:12 -0800 (PST) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [198.49.180.223]) by ietfa.amsl.com (Postfix) with ESMTP id 7363721F84E0 for ; Thu, 8 Mar 2012 11:48:12 -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 q28JmAOj026599 for ; Thu, 8 Mar 2012 11:48:10 -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, 8 Mar 2012 11:48:11 -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_01CCFD64.64983604" Date: Thu, 8 Mar 2012 11:48:07 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF74083E03D4@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: test message Thread-Index: Acz9ZGJ6VovM+hTjSBCUmUji/YWsKg== From: "Henry Lum" To: X-OriginalArrivalTime: 08 Mar 2012 19:48:11.0466 (UTC) FILETIME=[64AF2AA0:01CCFD64] Subject: [siprec] test message X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 19:48:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFD64.64983604 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please ignore this post. =20 Henry ------_=_NextPart_001_01CCFD64.64983604 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please ignore this post.

 

Henry

------_=_NextPart_001_01CCFD64.64983604-- From internet-drafts@ietf.org Thu Mar 8 20:01:25 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9180E21F8541; Thu, 8 Mar 2012 20:01:25 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laSXbMSOS2MS; Thu, 8 Mar 2012 20:01:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C1521F8539; Thu, 8 Mar 2012 20:01:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120309040125.6268.70679.idtracker@ietfa.amsl.com> Date: Thu, 08 Mar 2012 20:01:25 -0800 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-protocol-03.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 04:01:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Recording Working Group of the IE= TF. Title : Session Recording Protocol Author(s) : Leon Portman Henry Lum Alan Johnston Andrew Hutton Filename : draft-ietf-siprec-protocol-03.txt Pages : 26 Date : 2012-03-08 This document specifies the use of the Session Initiation Protocol (SIP), the Session Description Protocol (SDP), and the Real Time Protocol (RTP) for delivering real-time media and metadata from a Communication Session (CS) to a recording device. The Session Recording Protocol specifies the use of SIP, SDP, and RTP to establish a Recording Session (RS) between the Session Recording Client (SRC), which is on the path of the CS, and a Session Recording Server (SRS) at the recording device. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-siprec-protocol-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-protocol-03.txt From Henry.Lum@genesyslab.com Thu Mar 8 20:02:18 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39ABA21E804B for ; Thu, 8 Mar 2012 20:02:18 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nS9d39PwmLZ for ; Thu, 8 Mar 2012 20:02:17 -0800 (PST) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [198.49.180.223]) by ietfa.amsl.com (Postfix) with ESMTP id 5546F21E8052 for ; Thu, 8 Mar 2012 20:02:17 -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 q2942FYc007733 for ; Thu, 8 Mar 2012 20:02:15 -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, 8 Mar 2012 20:02:16 -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_01CCFDA9.6AA17130" Date: Thu, 8 Mar 2012 20:02:09 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF74083E04E2@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: summary of changes for draft-ietf-siprec-protocol-03 Thread-Index: Acz9qWZU8so1Iv/PTTuSBvETb2PUaQ== From: "Henry Lum" To: X-OriginalArrivalTime: 09 Mar 2012 04:02:16.0911 (UTC) FILETIME=[6ABF15F0:01CCFDA9] Subject: [siprec] summary of changes for draft-ietf-siprec-protocol-03 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 04:02:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFDA9.6AA17130 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is a summary of changes in protocol draft 03: =20 1) Email thread "Is siprec metadata mandatory to implement?"=20 many agreed on a) siprec option tag in a Supported/Require header means an RS is supported/required AND XML metadata is supported/required for this RS =20 Rewording Section 5.1 =20 "An SRC MUST include the "siprec" option tag in the Require header when initiating a Recording Session so that UA's which do not support the session recording protocol extensions will simply reject the INVITE request with a 420 Bad Extension." =20 and Section 5.2 =20 "An SRS MUST include the "siprec" option tag in the Require header as per [RFC3261] when initiating a Recording Session so that UA's which do not support the session recording protocol extensions will simply reject the INVITE request with a 420 Bad Extension." =20 2) Explain the reuse of label attribute for media streams that are removed and later added to the recording session =20 Section 6.1, added the following sentence in 1st paragraph =20 "The scope of the label name only applies to the same SIP message as the SDP,=20 meaning that the label name can be reused by another media stream within the=20 same recording session." =20 3) allow the SRS to remove media streams in the recording session =20 Section 6.2 inserted paragraph after the first one =20 "Over the lifetime of a recording session, the SRS can remove recorded streams from the recording session for various reasons. To remove a recorded stream from the recording session, the SRS sends a new SDP offer where the port of the media stream to be removed is set to zero, according to the procedures in [RFC3264]." =20 4) snapshot request issue below; that was the main debate since the last ietf meeting. Andy has a good summary here that I agree with. > 1. An explicit snapshot request MUST be in an UPDATE without SDP. >=20 > 2. The snaphot MUST be in either an UPDATE or a reINVITE both of which=20 > MUST have SDP. I would be ok with mandating it be only in an UPDATE=20 > but I think it is not necessary. >=20 > 3. The SRS MAY generate a reINVITE without SDP but this MUST not=20 > include a snapshot request. =20 Based on the summary, here are the changes: =20 Section 8.1 paragraph 3 "...When the SRC sends a full metadata snapshot, the SRC MUST send an INVITE or an UPDATE request with an SDP offer and the "recording-session" disposition." =20 Section 8.2 paragraph 3 =20 "When the SRS explicitly requests for a full metadata snapshot, the SRS MUST send an UPDATE request without an SDP offer. A metadata snapshot request contains a content with the content disposition type "recording-session". Note that the SRS MAY generate an INVITE request without an SDP offer but this MUST not include a metadata snapshot request." =20 5) multiplexing of rtp/rtcp; I commented that we should not mention RFC5761 at all in the protocol draft =20 6) rename feature tags from src to "+sip.src" and srs to "+sip.srs" =20 7) extend record and recordpref SDP attribute to session level (currently only media level) =20 8) SRC and SRS feature tags in REGISTER =20 make this MUST when an SRC or SRS registers =20 Section 5.1, paragraph 2 =20 "...In addition, when an SRC sends a REGISTER request to a registrar, the SRC MUST include the '+sip.src' feature tag to indicate the that it is a SRC." =20 Section 5.2, paragraph 2 =20 "...In addition, when an SRS sends a REGISTER request to a registrar, the SRS MUST include the '+sip.srs' feature tag to indicate that it is a SRS." =20 9) Address Andy's and Gonzalo's comments =20 =20 Regards, Henry ------_=_NextPart_001_01CCFDA9.6AA17130 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here is a summary of changes in protocol draft = 03:

 

1) Email thread "Is siprec metadata mandatory = to implement?"

many agreed on a) siprec option tag in a = Supported/Require header means an RS is supported/required AND XML metadata is = supported/required for this RS

 

Rewording Section 5.1

 

"An SRC MUST include the = "siprec"

   option tag in the Require header when = initiating a Recording Session

   so that UA's which do not support the = session recording protocol

   extensions will simply reject the = INVITE request with a 420 Bad

   Extension."

 

and Section 5.2

 

"An SRS MUST include the "siprec" = option tag in the Require header as

   per [RFC3261] when initiating a = Recording Session so that UA's which

   do not support the session recording = protocol extensions will simply

   reject the INVITE request with a 420 = Bad Extension."

  

2) Explain the reuse of label attribute for media = streams that are removed and later added to the recording session

 

Section 6.1, added the following sentence in 1st = paragraph

 

"The scope of the label name only applies to = the same SIP message as the SDP,

 meaning that the label name can be reused by = another media stream within the

 same recording session."

 

3) allow the SRS to remove media streams in the = recording session

 

Section 6.2 inserted paragraph after the first = one

 

   "Over the lifetime of a recording = session, the SRS can remove recorded

   streams from the recording session for = various reasons.  To remove a

   recorded stream from the recording = session, the SRS sends a new SDP

   offer where the port of the media = stream to be removed is set to

   zero, according to the procedures in = [RFC3264]."

 

4) snapshot request issue below; that was the main = debate since the last ietf meeting. Andy has a good summary here that I agree = with.

         &= nbsp;      > 1. An explicit snapshot request = MUST be in an UPDATE without SDP.

         &= nbsp;      >

         &= nbsp;      > 2. The snaphot MUST be in = either an UPDATE or a reINVITE both of which

         &= nbsp;      > MUST have SDP. I would be ok = with mandating it be only in an UPDATE

         &= nbsp;      > but I think it is not = necessary.

         &= nbsp;      >

         &= nbsp;      > 3. The SRS MAY generate a = reINVITE without SDP but this MUST not

         &= nbsp;      > include a snapshot = request.

 

Based on the summary, here are the = changes:

         &= nbsp;     

Section 8.1 paragraph 3

"...When the SRC sends a full metadata = snapshot, the SRC MUST

   send an INVITE or an UPDATE request = with an SDP offer and the

   "recording-session" = disposition."

         &= nbsp;     

Section 8.2 paragraph 3

 

"When the SRS explicitly requests for a full = metadata snapshot, the

   SRS MUST send an UPDATE request = without an SDP offer.  A metadata

   snapshot request contains a content = with the content disposition type

   "recording-session".  = Note that the SRS MAY generate an INVITE

   request without an SDP offer but this = MUST not include a metadata

   snapshot request."

 

5) multiplexing of rtp/rtcp; I commented that we = should not mention RFC5761 at all in the protocol draft

 

6) rename feature tags from src to = "+sip.src" and srs to "+sip.srs"

 

7) extend record and recordpref SDP attribute to = session level (currently only media level)

 

8) SRC and SRS feature tags in = REGISTER

 

make this MUST when an SRC or SRS = registers

 

Section 5.1, paragraph 2

 

"...In addition, when an SRC sends a REGISTER = request

   to a registrar, the SRC MUST include = the '+sip.src' feature tag to

   indicate the that it is a = SRC."

 

Section 5.2, paragraph 2

 

"...In addition, when

   an SRS sends a REGISTER request to a = registrar, the SRS MUST include

   the '+sip.srs' feature tag to indicate = that it is a SRS."

  

9) Address Andy's and Gonzalo's = comments

 

 

Regards,

Henry

------_=_NextPart_001_01CCFDA9.6AA17130-- From trac+siprec@trac.tools.ietf.org Thu Mar 8 20:05:40 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3348721E804B for ; Thu, 8 Mar 2012 20:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mtg0pFQFkvyH for ; Thu, 8 Mar 2012 20:05:39 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id B15CC21E803D for ; Thu, 8 Mar 2012 20:05:39 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S5r54-0006wE-1e; Thu, 08 Mar 2012 23:05:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "siprec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-siprec-protocol@tools.ietf.org, henry.lum@genesyslab.com X-Trac-Project: siprec Date: Fri, 09 Mar 2012 04:05:26 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/83#comment:1 Message-ID: <092.e05258ac154689476d4da524f079dcbd@trac.tools.ietf.org> References: <077.0021af1f6889a3d61f7d2f0642166001@trac.tools.ietf.org> X-Trac-Ticket-ID: 83 In-Reply-To: <077.0021af1f6889a3d61f7d2f0642166001@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-siprec-protocol@tools.ietf.org, henry.lum@genesyslab.com, siprec@ietf.org X-SA-Exim-Mail-From: trac+siprec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120309040539.B15CC21E803D@ietfa.amsl.com> Resent-Date: Thu, 8 Mar 2012 20:05:39 -0800 (PST) Resent-From: trac+siprec@trac.tools.ietf.org Cc: siprec@ietf.org Subject: Re: [siprec] #83: Need agreement on what to say about feature tags in REGISTER X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 04:05:40 -0000 #83: Need agreement on what to say about feature tags in REGISTER Comment (by henry.lum@…): Fixed in draft -03 make this MUST when an SRC or SRS registers Section 5.1, paragraph 2 "...In addition, when an SRC sends a REGISTER request to a registrar, the SRC MUST include the '+sip.src' feature tag to indicate the that it is a SRC." Section 5.2, paragraph 2 "...In addition, when an SRS sends a REGISTER request to a registrar, the SRS MUST include the '+sip.srs' feature tag to indicate that it is a SRS." -- -----------------------------+------------------------------------------- Reporter: andrew.hutton@… | Owner: draft-ietf-siprec-protocol@… Type: task | Status: new Priority: minor | Milestone: Component: protocol | Version: Severity: - | Resolution: Keywords: | -----------------------------+------------------------------------------- Ticket URL: siprec From trac+siprec@trac.tools.ietf.org Thu Mar 8 20:05:44 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017B121E8052 for ; Thu, 8 Mar 2012 20:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByfuJLKDt653 for ; Thu, 8 Mar 2012 20:05:43 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 845B221E801C for ; Thu, 8 Mar 2012 20:05:43 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S5r5I-00073Q-Kl; Thu, 08 Mar 2012 23:05:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "siprec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-siprec-protocol@tools.ietf.org, henry.lum@genesyslab.com X-Trac-Project: siprec Date: Fri, 09 Mar 2012 04:05:40 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/83#comment:2 Message-ID: <092.562d737f2b581d448b347ec3e2071433@trac.tools.ietf.org> References: <077.0021af1f6889a3d61f7d2f0642166001@trac.tools.ietf.org> X-Trac-Ticket-ID: 83 In-Reply-To: <077.0021af1f6889a3d61f7d2f0642166001@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-siprec-protocol@tools.ietf.org, henry.lum@genesyslab.com, siprec@ietf.org X-SA-Exim-Mail-From: trac+siprec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120309040543.845B221E801C@ietfa.amsl.com> Resent-Date: Thu, 8 Mar 2012 20:05:43 -0800 (PST) Resent-From: trac+siprec@trac.tools.ietf.org Cc: siprec@ietf.org Subject: Re: [siprec] #83: Need agreement on what to say about feature tags in REGISTER X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 04:05:44 -0000 #83: Need agreement on what to say about feature tags in REGISTER Changes (by henry.lum@…): * status: new => closed * resolution: => fixed -- -----------------------------+------------------------------------------- Reporter: andrew.hutton@… | Owner: draft-ietf-siprec-protocol@… Type: task | Status: closed Priority: minor | Milestone: Component: protocol | Version: Severity: - | Resolution: fixed Keywords: | -----------------------------+------------------------------------------- Ticket URL: siprec From trac+siprec@trac.tools.ietf.org Thu Mar 8 20:06:56 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0729F21E803D for ; Thu, 8 Mar 2012 20:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCK4uRidQNC2 for ; Thu, 8 Mar 2012 20:06:55 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7879821E801C for ; Thu, 8 Mar 2012 20:06:55 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S5r6T-0007I3-Pf; Thu, 08 Mar 2012 23:06:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "siprec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-siprec-protocol@tools.ietf.org, henry.lum@genesyslab.com X-Trac-Project: siprec Date: Fri, 09 Mar 2012 04:06:53 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/79#comment:1 Message-ID: <070.da8b1c402bf5c601326e6f2f254255e6@trac.tools.ietf.org> References: <055.41c9f5d9c9a876b6ae1c772f80a78544@trac.tools.ietf.org> X-Trac-Ticket-ID: 79 In-Reply-To: <055.41c9f5d9c9a876b6ae1c772f80a78544@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-siprec-protocol@tools.ietf.org, henry.lum@genesyslab.com, siprec@ietf.org X-SA-Exim-Mail-From: trac+siprec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120309040655.7879821E801C@ietfa.amsl.com> Resent-Date: Thu, 8 Mar 2012 20:06:55 -0800 (PST) Resent-From: trac+siprec@trac.tools.ietf.org Cc: siprec@ietf.org Subject: Re: [siprec] #79: Review mechanism for triggering and responding for metadata snapshot request X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 04:06:56 -0000 #79: Review mechanism for triggering and responding for metadata snapshot request Changes (by henry.lum@…): * status: new => closed * resolution: => fixed Comment: Andy has provided a summary that were agreed upon. > 1. An explicit snapshot request MUST be in an UPDATE without SDP. > > 2. The snaphot MUST be in either an UPDATE or a reINVITE both of which > MUST have SDP. I would be ok with mandating it be only in an UPDATE > but I think it is not necessary. > > 3. The SRS MAY generate a reINVITE without SDP but this MUST not > include a snapshot request. Based on the summary, here are the changes: Section 8.1 paragraph 3 "...When the SRC sends a full metadata snapshot, the SRC MUST send an INVITE or an UPDATE request with an SDP offer and the "recording-session" disposition." Section 8.2 paragraph 3 "When the SRS explicitly requests for a full metadata snapshot, the SRS MUST send an UPDATE request without an SDP offer. A metadata snapshot request contains a content with the content disposition type "recording-session". Note that the SRS MAY generate an INVITE request without an SDP offer but this MUST not include a metadata snapshot request." -- ----------------------+------------------------------------------- Reporter: leonp@… | Owner: draft-ietf-siprec-protocol@… Type: defect | Status: closed Priority: major | Milestone: Component: protocol | Version: 2.0 Severity: - | Resolution: fixed Keywords: | ----------------------+------------------------------------------- Ticket URL: siprec From trac+siprec@trac.tools.ietf.org Thu Mar 8 20:07:57 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9501B21E804B for ; Thu, 8 Mar 2012 20:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8LMb8zLm-96 for ; Thu, 8 Mar 2012 20:07:57 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2696F21E801C for ; Thu, 8 Mar 2012 20:07:57 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S5r7U-0007Ia-ER; Thu, 08 Mar 2012 23:07:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "siprec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: leonp@nice.com, henry.lum@genesyslab.com X-Trac-Project: siprec Date: Fri, 09 Mar 2012 04:07:56 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/84#comment:2 Message-ID: <070.a90117932760d8932a800bafcf6e78de@trac.tools.ietf.org> References: <055.c8b9f781028eccb5f9b33ce1ede88fcf@trac.tools.ietf.org> X-Trac-Ticket-ID: 84 In-Reply-To: <055.c8b9f781028eccb5f9b33ce1ede88fcf@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: leonp@nice.com, henry.lum@genesyslab.com, siprec@ietf.org X-SA-Exim-Mail-From: trac+siprec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: siprec@ietf.org Subject: Re: [siprec] #84: State that label scope being limited to the metadata carried in the same SIP message as the SDP X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 04:07:57 -0000 #84: State that label scope being limited to the metadata carried in the same SIP message as the SDP Changes (by henry.lum@…): * status: new => closed * resolution: => fixed Comment: Section 6.1, added the following sentence in 1st paragraph "The scope of the label name only applies to the same SIP message as the SDP, meaning that the label name can be reused by another media stream within the same recording session." -- -------------------------+---------------------- Reporter: leonp@… | Owner: leonp@… Type: enhancement | Status: closed Priority: major | Milestone: Component: protocol | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+---------------------- Ticket URL: siprec From trac+siprec@trac.tools.ietf.org Thu Mar 8 20:10:33 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599E721E8052 for ; Thu, 8 Mar 2012 20:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nHtNCAN+7aW for ; Thu, 8 Mar 2012 20:10:32 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id D7C7021E801C for ; Thu, 8 Mar 2012 20:10:32 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S5r9y-0007kj-MV; Thu, 08 Mar 2012 23:10:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "siprec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-siprec-protocol@tools.ietf.org, henry.lum@genesyslab.com X-Trac-Project: siprec Date: Fri, 09 Mar 2012 04:10:30 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/82#comment:1 Message-ID: <092.8688165e7f6163d5ba0b713b2d21f3c8@trac.tools.ietf.org> References: <077.45a92b02c410d1c02070ca65d37bd2cc@trac.tools.ietf.org> X-Trac-Ticket-ID: 82 In-Reply-To: <077.45a92b02c410d1c02070ca65d37bd2cc@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-siprec-protocol@tools.ietf.org, henry.lum@genesyslab.com, siprec@ietf.org X-SA-Exim-Mail-From: trac+siprec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120309041032.D7C7021E801C@ietfa.amsl.com> Resent-Date: Thu, 8 Mar 2012 20:10:32 -0800 (PST) Resent-From: trac+siprec@trac.tools.ietf.org Cc: siprec@ietf.org Subject: Re: [siprec] #82: Support for RTP/RTCP Mux (RFC 5761) in SIPREC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 04:10:33 -0000 #82: Support for RTP/RTCP Mux (RFC 5761) in SIPREC Changes (by henry.lum@…): * status: new => closed * resolution: => fixed Comment: The conclusion is that we should not mention RFC5671 at all in this draft as it would imply that it is mandatory to support. -- -----------------------------+------------------------------------------- Reporter: andrew.hutton@… | Owner: draft-ietf-siprec-protocol@… Type: task | Status: closed Priority: major | Milestone: Component: protocol | Version: Severity: - | Resolution: fixed Keywords: | -----------------------------+------------------------------------------- Ticket URL: siprec From andrew.hutton@siemens-enterprise.com Fri Mar 9 02:48:07 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B247D21F862F for ; Fri, 9 Mar 2012 02:48: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.098, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxm1PMXluW-t for ; Fri, 9 Mar 2012 02:48:07 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id D4B2021F8629 for ; Fri, 9 Mar 2012 02:48:06 -0800 (PST) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 572E723F0423 for ; Fri, 9 Mar 2012 11:48:05 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 9 Mar 2012 11:48:05 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Date: Fri, 9 Mar 2012 11:48:03 +0100 Thread-Topic: I-D Action: draft-ietf-siprec-protocol-03.txt Thread-Index: Acz9qVceas/A/kqyTbePrVN70SX5TAAOKY8w Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312946BC400@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] FW: I-D Action: draft-ietf-siprec-protocol-03.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 10:48:07 -0000 FYI. -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: 09 March 2012 04:01 To: i-d-announce@ietf.org Cc: siprec@ietf.org Subject: I-D Action: draft-ietf-siprec-protocol-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Recording Working Group of the IE= TF. Title : Session Recording Protocol Author(s) : Leon Portman Henry Lum Alan Johnston Andrew Hutton Filename : draft-ietf-siprec-protocol-03.txt Pages : 26 Date : 2012-03-08 This document specifies the use of the Session Initiation Protocol (SIP), the Session Description Protocol (SDP), and the Real Time Protocol (RTP) for delivering real-time media and metadata from a Communication Session (CS) to a recording device. The Session Recording Protocol specifies the use of SIP, SDP, and RTP to establish a Recording Session (RS) between the Session Recording Client (SRC), which is on the path of the CS, and a Session Recording Server (SRS) at the recording device. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-siprec-protocol-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-protocol-03.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From andrew.hutton@siemens-enterprise.com Fri Mar 9 06:40:49 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608A721F8609 for ; Fri, 9 Mar 2012 06:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFbh4bOrzoK6 for ; Fri, 9 Mar 2012 06:40:48 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id D5ABF21F8564 for ; Fri, 9 Mar 2012 06:40:47 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id CCBF41EB8502; Fri, 9 Mar 2012 15:40:46 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 9 Mar 2012 15:40:46 +0100 From: "Hutton, Andrew" To: "john.2.stafford@bt.com" Date: Fri, 9 Mar 2012 15:40:43 +0100 Thread-Topic: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream Thread-Index: Acz7H+utWOk0o6HnS5mpHa+/rKi9XACxTO0w Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312946BC5E3@MCHP058A.global-ad.net> References: , <4F4E43D3.8070508@alum.mit.edu> , <387F9047F55E8C42850AD6B3A7A03C6C0E068E45@inba-mail01.sonusnet.com> , <4F4FB6EA.8050203@alum.mit.edu> <4F553F1C.9070400@alum.mit.edu> In-Reply-To: <4F553F1C.9070400@alum.mit.edu> 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] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 14:40:49 -0000 Hi John, I am also struggling to understand this use case. If you mean that you want to have the SRC act as an RTP Mixer and mix the s= treams from different CS's in to a single RTP Session using the CSRC to dem= ultiplex at the SRS then I think this is not supported by the current metad= ata model. Could our metadata experts please confirm? Regards Andy > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 05 March 2012 22:33 > To: john.2.stafford@bt.com > Cc: siprec@ietf.org > Subject: Re: [siprec] How to specify in metadata that multiple CS's are > being recorded in a single mixed RS m line stream >=20 > On 3/5/12 11:45 AM, john.2.stafford@bt.com wrote: > > Ok, CSG is not a concern. > > > > What I wanted clarified was how metadatas and would look when > you have two simultaneous calls on an endpoint and both calls are mixed > into a single recorder stream. > > > > If represents the mixed stream of two calls going to the > recorder, then how can a participant have a that references that > stream, > > as a participant does NOT recv the mixed stream. >=20 > I don't understand how it makes sense to mix the media for two distinct > calls. >=20 > Or do you mean that you want to send them both over a single RTP > session, distinguished by SSRC or CSRC? >=20 > Thanks, > Paul >=20 > > > > Rgds > > John Stafford | Solution Architect 1 | BT Global Services > > ________________________________________ > > From: Paul Kyzivat [pkyzivat@alum.mit.edu] > > Sent: 01 March 2012 17:50 > > To: Stafford,J,John,JRJ3X C > > Cc: pravindran@sonusnet.com; siprec@ietf.org > > Subject: Re: [siprec] How to specify in metadata that multiple CS's > are being recorded in a single mixed RS m line stream > > > > On 3/1/12 3:53 AM, john.2.stafford@bt.com wrote: > >> Partha, > >> > >> I cant see how using CSG will help with the describing of the > streams. > >> Also I'm not convinced this would be the correct usage of a CSG, as > while the calls are associated as they are made by the same person, in > terms of sip they are completely unrelated. > >> I think draft-ietf-metadata could do with an explanation of what > relationships a CSG implies. > > > > Its your call whether these calls are related in a way that you want > to > > track as a CSG. > > > > Clearly there are a number of different reasons you might want to > group > > CSs, and we currently don't provide any attributes to distinguish one > > reason from another. That is mostly because we didn't want to get > into > > the business of enumerating the possible uses. The solution to that > is > > to add proprietary extension data to the CSG and/or the CSs to > identify > > why they are grouped. > > > > Alternatively I would simply treat these as two separate CSs, each > with > > a separate media stream. > > > > Thanks, > > Paul > > > >> Rgds > >> John Stafford | Solution Architect 1 | BT Global Services > >> ________________________________________ > >> From: Ravindran, Parthasarathi [pravindran@sonusnet.com] > >> Sent: 01 March 2012 01:31 > >> To: Stafford,J,John,JRJ3X C; pkyzivat@alum.mit.edu; siprec@ietf.org > >> Subject: RE: [siprec] How to specify in metadata that multiple CS's > are being recorded in a single mixed RS m line stream > >> > >> John, > >> > >> I guess that you are looking for group (CSG) element usage. Person > AC sessions has to be grouped under single group. CS AC-B has to be > mentioned as one of the session in group and CS AC-D has to be > mentioned as another session of the group. Here, user AC is available > in both sessions wherein participant (device) A is in session1 and > participant (device) C is in session2, it is possible to pass > participant name as AC in both sessions and it is perfectly fine. > Please let me know whether this approach solves your problem. > >> > >> Thanks > >> Partha > >> > >>> -----Original Message----- > >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > >>> Of john.2.stafford@bt.com > >>> Sent: Wednesday, February 29, 2012 11:36 PM > >>> To: pkyzivat@alum.mit.edu; siprec@ietf.org > >>> Subject: Re: [siprec] How to specify in metadata that multiple CS's > are > >>> being recorded in a single mixed RS m line stream > >>> > >>> Paul, > >>> > >>> Its one person AC with two handsets both in use at same time, > probably > >>> one to each ear. > >>> > >>> Rgds > >>> John Stafford | Solution Architect 1 | BT Global Services > >>> ________________________________________ > >>> From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf > Of > >>> Paul Kyzivat [pkyzivat@alum.mit.edu] > >>> Sent: 29 February 2012 15:27 > >>> To: siprec@ietf.org > >>> Subject: Re: [siprec] How to specify in metadata that multiple CS's > are > >>> being recorded in a single mixed RS m line stream > >>> > >>> On 2/29/12 9:29 AM, john.2.stafford@bt.com wrote: > >>>> A converse of the "How to specify in metadata that a participants > >>> stream is being recorded in multiple m line streams" thread: > >>>> > >>>> Another of our record configurations is when a turret's handset 1 > and > >>>> handset 2 calls are recorded as a single mixed recorder stream > >>>> > >>>> once again a persistent RS will be set up at registration time, in > >>> this case there will be a single m line. > >>>> > >>>> So if represents a record stream, how would the > following be > >>> described in metadata: > >>>> > >>>> There are 2 calls, A-B and C-D, both are recorded via a single > >>> stream. > >>>> participants A and C are the same person, making two calls on > handset > >>> 1 and handset 2 of their turret. > >>> > >>> Just to clarify: > >>> > >>> There is one person, call him AC, that has two handsets A and C. > >>> AC has established one call with B (CS-A-B) and another call with D > (CS- > >>> C-D). > >>> > >>> I gather these calls go on in parallel. (Maybe AC is switching back > and > >>> forth taking into one handset of the other. In principal he could > put > >>> one to each ear and use both at the same time.) > >>> > >>> Or is this more like a two line phone, with radio buttons to switch > >>> between the two lines, so that at any given time one is active and > the > >>> other is "on hold"? > >>> > >>> I won't even try to respond to the stuff below until I get clarity > on > >>> the above. > >>> > >>> Thanks, > >>> Paul > >>> > >>>> The problems I have in describing this in metadata are: > >>>> 1. I dont know how to show what the participants, as they > dont > >>> recv the 2 call mixed stream. > >>>> 2. I only have a single stream being recorded which includes 2 > CS's, > >>>> but the element can only have a single session > attriibute > >>>> > >>>> I can only describe this using > >>> and. I have not been following the list > too > >>> closely for the past couple of months, is it still the intention to > use > >>> these elements, as I see there is not yet a draft-ietf-metadata- > 06.txt > >>> that includes these elements in xml schema and examples. > >>>> > >>>> Also I dont know what happens to when using > >>> associations. > >>>> > >>>> Anyway, heres my stab at it, > >>>> > >>>> > >>>> > >>>> complete > >>>> > >>>> > >>>> >>>> id=3D"=3D=3DPARTICIPANT_A=3D=3D" > >>>> > >>>> RamMohan > R > >>>> > >>>> > >>>> >>>> participant=3D"=3D=3DPARTICIPANT_A=3D=3D" > >>>> session=3D"=3D=3D=3D=3DSESSION_ONE=3D=3D=3D=3D=3D= "> > >>>> 2010-12- > 16T23:41:07Z >>> time> > >>>> TBD > >>>> > >>>> >>>> participant=3D"=3D=3DPARTICIPANT_A=3D=3D" > >>>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> > >>>> 2010-12- > 16T23:41:07Z >>> time> > >>>> > >>>> > >>>> >>>> id=3D"=3D=3DPARTICIPANT_B=3D=3D" > >>>> > >>>> Paul > Kyzivat > >>>> > >>>> > >>>> >>>> participant=3D"=3D=3DPARTICIPANT_B=3D=3D" > >>>> session=3D"=3D=3D=3D=3DSESSION_ONE=3D=3D=3D=3D=3D= "> > >>>> 2010-12- > 16T23:41:07Z >>> time> > >>>> TBD > >>>> > >>>> >>>> participant=3D"=3D=3DPARTICIPANT_B=3D=3D" > >>>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> > >>>> 2010-12- > 16T23:41:07Z >>> time> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> >>>> id=3D"=3D=3DPARTICIPANT_C=3D=3D" > >>>> > >>>> RamMohan > R > >>>> > >>>> > >>>> >>>> participant=3D"=3D=3DPARTICIPANT_C=3D=3D" > >>>> session=3D"=3D=3D=3D=3DSESSION_TWO=3D=3D=3D=3D=3D= "> > >>>> 2010-12- > 16T22:02:04Z >>> time> > >>>> TBD > >>>> > >>>> >>>> participant=3D"=3D=3DPARTICIPANT_C=3D=3D" > >>>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> > >>>> 2010-12- > 16T22:02:04Z >>> time> > >>>> > >>>> > >>>> >>>> id=3D"=3D=3DPARTICIPANT_D=3D=3D" > >>>> > >>>> Andrew > >>> Hutton > >>>> > >>>> > >>>> >>>> participant=3D"=3D=3DPARTICIPANT_D=3D=3D" > >>>> session=3D"=3D=3D=3D=3DSESSION_TWO=3D=3D=3D=3D=3D= "> > >>>> 2010-12- > 16T22:02:04Z >>> time> > >>>> TBD > >>>> > >>>> >>>> participant=3D"=3D=3DPARTICIPANT_D=3D=3D" > >>>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> > >>>> 2010-12- > 16T22:02:04Z >>> time> > >>>> > >>>> > >>>> >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Rgds > >>>> John Stafford | Solution Architect 1 | BT Global Services > >>>> _______________________________________________ > >>>> 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 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Fri Mar 9 06:49:52 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC4621F8523 for ; Fri, 9 Mar 2012 06:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVN1dIkfYg74 for ; Fri, 9 Mar 2012 06:49:52 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id AA80E21F858B for ; Fri, 9 Mar 2012 06:49:51 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id E508723F051D; Fri, 9 Mar 2012 15:49:50 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 9 Mar 2012 15:49:50 +0100 From: "Hutton, Andrew" To: "Charles Eckel (eckelcu)" , Henry Lum , "brian.rosen@gmail.com" Date: Fri, 9 Mar 2012 15:49:49 +0100 Thread-Topic: SIPREC Protocol draft and merge of draft-eckel-siprec-rtp-rec-03 Thread-Index: Acz3vuHI0BO7jot3SmO9nq+Y5OInxAA1wqOwAVsupTA= Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312946BC5FE@MCHP058A.global-ad.net> References: <101C6067BEC68246B0C3F6843BCCC1E312945D5928@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] SIPREC Protocol draft and merge of draft-eckel-siprec-rtp-rec-03 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 14:49:52 -0000 Hi Charles, See below. Regards Andy > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > Sent: 02 March 2012 17:20 > To: Hutton, Andrew; Henry Lum; brian.rosen@gmail.com > Cc: siprec@ietf.org > Subject: RE: SIPREC Protocol draft and merge of draft-eckel-siprec-rtp- > rec-03 >=20 > Hi Andy, >=20 > Based on the comments and discussion at IETF 83, I think the following > additions to the draft would be beneficial: [AndyH] - Wow so you really can see the future. >=20 > 1) SSRC based multiplexing > Explicitly mention multiplexing using SSRC, not RTP session > multiplexing, and illustrate how a two party call may be recorded by a > B2BUA acting as an SRC, using either multiple m-lines or a single m- > line > toward the SRS. [AndyH] - Yes I think we need this but need to be careful about not replica= ted what is in the protocol draft especially if we decide to keep the RTP d= raft separate (See next e-mail). >=20 > Note, there was some discussion regarding two separate calls being > recorded in a single RS with single m-line? I do not think we need to > dive into this, but we can if others think it is important to do so. [AndyH] - I am thinking we might need to say whether this is allowed or not= especially if the metadata cannot support it. It relates to section 4.2 of= your draft which we might need to add some clarification. >=20 > 2) Split personality SRC > draft-eckel-siprec-rtp-rec-03 describes the RTP/RTCP handling expected > by SIPREC SRCs and SRSs, as well as SIPREC aware UAs and unaware UAs. > In > addition to the models stated currently, there is also a model in which > the SRC acts as an RTP/RTCP translator toward the UAs within the CS(s), > and as an RTP/RTCP endpoint toward the SRS for the corresponding RS. I > have not gotten my head around this model completely, but I think it > may > be a useful exercise to discuss and perhaps add corresponding text to > the draft. [AndyH] - Maybe I also have not got me head around that yet. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > > Sent: Thursday, March 01, 2012 7:21 AM > > To: Charles Eckel (eckelcu); Henry Lum; brian.rosen@gmail.com > > Cc: siprec@ietf.org > > Subject: SIPREC Protocol draft and merge of > draft-eckel-siprec-rtp-rec- > > 03 > > > > Hi All, > > > > We still have a place holder in draft-ietf-siprec-protocol for > > including text from draft-eckel-siprec-rtp-rec-03. > > > > What is holding is up with this do we need more review from AVT > experts > > or is it something else? > > > > I see from the Taipei minutes that "section 4.3 needs more text about > > various usages of RTP by mixers/translators". > > > > Charles, can you initiate discussion on the list to move this forward > > or let me know what other action we need to take. > > > > Regards > > Andy (SIPREC Co-Chair). From andrew.hutton@siemens-enterprise.com Fri Mar 9 06:56:38 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F27121F86B1 for ; Fri, 9 Mar 2012 06:56:38 -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.098, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1IuvMPLsMcv for ; Fri, 9 Mar 2012 06:56:38 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id CC04921F866D for ; Fri, 9 Mar 2012 06:56:37 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id E12E91EB83EE for ; Fri, 9 Mar 2012 15:56:33 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 9 Mar 2012 15:56:33 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Date: Fri, 9 Mar 2012 15:56:32 +0100 Thread-Topic: draft-eckel-siprec-rtp-rec-03 - Should we adopt in its own right. Thread-Index: Acz+BNDnrr4sVn7wTIWf9MiV5/IeIA== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312946BC60B@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] draft-eckel-siprec-rtp-rec-03 - Should we adopt in its own right. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 14:56:38 -0000 Hi All, So far we always planned to at some point merge http://tools.ietf.org/html/= draft-eckel-siprec-rtp-rec-03 with our protocol draft (http://tools.ietf.or= g/html/draft-ietf-siprec-protocol-03). However maybe it would be a good idea to keep these separate and adopt draf= t-eckel-siprec-rtp-rec-*. I envisage that it would maintain its current st= ates as "informational" only. I would be interested in the opinions of the group on this. Regards Andy (SIPREC Co-Chair). From leon.portman@gmail.com Fri Mar 9 07:36:23 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B264F21F8692 for ; Fri, 9 Mar 2012 07:36:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSWKJ1DZULwA for ; Fri, 9 Mar 2012 07:36:23 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 426B821F863E for ; Fri, 9 Mar 2012 07:36:18 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so1219704wgb.13 for ; Fri, 09 Mar 2012 07:36:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=r7P/y1SB6qTsfDKypFFD60GX+gt+RsIg3AAjzz896kQ=; b=fFwmQ8VFCFnLyxTspRpqTvv9G+A7DkvwWMMB7SkWez6cMNfD+6I/SleHSCMkFnjtyL 9O9W7PWADET57vZLcfLDUVm/aqWXxyXHwFhWR4keWIsl+PD8Pm8uU7CzMNJlGYtXNIl1 w66PAQj2AOKCjsaSq92e9GwnezhtLVhDR98mX83MZs3ArpcWYSX1af+BImBOwiOCJOic zUMq0MqqZ196OAPaEvl17tn7w7ckT24vfV/w+IZv11L995Qgci1MA1CNfmXoeyP/FjTj t45+irBnnSmw6EMe1T/UQhWH3IZ7TMkAuT7roMYp2xQeaWSMfkjvQ/5qZO90w7t+JZqk K5ew== Received: by 10.180.101.136 with SMTP id fg8mr5878626wib.4.1331307377380; Fri, 09 Mar 2012 07:36:17 -0800 (PST) Received: from [192.168.1.108] ([212.150.140.190]) by mx.google.com with ESMTPS id fl2sm11392200wib.4.2012.03.09.07.36.14 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Mar 2012 07:36:15 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1426\)) From: Leon Portman In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312946BC60B@MCHP058A.global-ad.net> Date: Fri, 9 Mar 2012 17:36:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2DF581AD-6000-4642-8323-ED65106FFBA3@gmail.com> References: <101C6067BEC68246B0C3F6843BCCC1E312946BC60B@MCHP058A.global-ad.net> To: "Hutton, Andrew" X-Mailer: Apple Mail (2.1426) Cc: "siprec@ietf.org" Subject: Re: [siprec] draft-eckel-siprec-rtp-rec-03 - Should we adopt in its own right. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 15:36:23 -0000 I am ok with both options.=20 Leon On Mar 9, 2012, at 4:56 PM, "Hutton, Andrew" = wrote: > Hi All, >=20 > So far we always planned to at some point merge = http://tools.ietf.org/html/draft-eckel-siprec-rtp-rec-03 with our = protocol draft = (http://tools.ietf.org/html/draft-ietf-siprec-protocol-03). >=20 > However maybe it would be a good idea to keep these separate and adopt = draft-eckel-siprec-rtp-rec-*. I envisage that it would maintain its = current states as "informational" only. >=20 > I would be interested in the opinions of the group on this. >=20 > Regards > Andy (SIPREC Co-Chair). >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Fri Mar 9 08:29:03 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F368A21F8550 for ; Fri, 9 Mar 2012 08:29:02 -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.096, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bj2nYxZu3sUU for ; Fri, 9 Mar 2012 08:29:02 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7052D21F854D for ; Fri, 9 Mar 2012 08:29:02 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id A80F21EB84A8 for ; Fri, 9 Mar 2012 17:29:01 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 9 Mar 2012 17:29:01 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Date: Fri, 9 Mar 2012 17:29:00 +0100 Thread-Topic: SIPREC IETF83 - Draft Agenda Thread-Index: Acz+Ebv2NnpuKnMXTeiwf4SN9WYwuQ== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312946BC6C1@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] SIPREC IETF83 - Draft Agenda X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 16:29:03 -0000 Hi All, I uploaded a draft agenda for the SIPREC session at IETF83 (See http://www.= ietf.org/proceedings/83/agenda/agenda-83-siprec.html). Please can those listed as presenting let me know if they are ok with the t= ime allocated? Comments and suggestions are most welcome. Regards Andy (SIPREC Co-Chair). From leon.portman@gmail.com Fri Mar 9 08:30:53 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8423121F86A0 for ; Fri, 9 Mar 2012 08:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltnoDuMwrJO5 for ; Fri, 9 Mar 2012 08:30:53 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id BD70821F8571 for ; Fri, 9 Mar 2012 08:30:52 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so1257517wgb.13 for ; Fri, 09 Mar 2012 08:30:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=E0Y2AJLwsHiJAsiSbRKA4cuH9/pkguVT/aFy/0LKjjk=; b=QwAC58Z2WOQIy8H2Dl7v5gCG4ftbOD6PnkbN0C9z036IqDqaFqhkh6WtG1VAzlN/i9 mXyaZbYWT+pjNQLy9Li291+vmgXyLhXIUScQjNS6GwS6L/qhFKWrtGPENaftsfwNMo+E nL1hiiK3TFj19Vk7ayVs/YKNv+03K4MLDwLHoeKm9i0Dm5ZInrqoaun57zrPWmDa//Xu yiF+uytr4rkJj7kbshueZGLkphkb9gRnTpGG0OqiTmdjxjdkPfbeAi1tXsir1svgq0rB 1RJTZIL84tprkbs4dOCJ4DsjYxZOt4M4CPnvjFjyJ8PPGEaSxtNE3txforu3KOQ2ETSh R2bQ== Received: by 10.180.97.41 with SMTP id dx9mr6255142wib.9.1331310651983; Fri, 09 Mar 2012 08:30:51 -0800 (PST) Received: from [192.168.1.108] ([212.150.140.190]) by mx.google.com with ESMTPS id j3sm12050536wiw.1.2012.03.09.08.30.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Mar 2012 08:30:51 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1426\)) From: Leon Portman In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312946BC6C1@MCHP058A.global-ad.net> Date: Fri, 9 Mar 2012 18:30:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <48EA11FA-056B-405C-8021-5CD506796CA1@gmail.com> References: <101C6067BEC68246B0C3F6843BCCC1E312946BC6C1@MCHP058A.global-ad.net> To: "Hutton, Andrew" X-Mailer: Apple Mail (2.1426) Cc: "siprec@ietf.org" Subject: Re: [siprec] SIPREC IETF83 - Draft Agenda X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 16:30:53 -0000 Andy Thanks I am good Leon On Mar 9, 2012, at 6:29 PM, "Hutton, Andrew" = wrote: > Hi All, >=20 > I uploaded a draft agenda for the SIPREC session at IETF83 (See = http://www.ietf.org/proceedings/83/agenda/agenda-83-siprec.html). >=20 > Please can those listed as presenting let me know if they are ok with = the time allocated? >=20 > Comments and suggestions are most welcome. >=20 > Regards > Andy (SIPREC Co-Chair). > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From Henry.Lum@genesyslab.com Fri Mar 9 08:53:55 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76CC421F8684 for ; Fri, 9 Mar 2012 08:53:55 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBYyPE4qEDtq for ; Fri, 9 Mar 2012 08:53:54 -0800 (PST) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF9421F86B8 for ; Fri, 9 Mar 2012 08:53:54 -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 q29GrrdI029548; Fri, 9 Mar 2012 08:53: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); Fri, 9 Mar 2012 08:53: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: Fri, 9 Mar 2012 08:53:52 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF74083E05E5@NAHALD.us.int.genesyslab.com> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312946BC6C1@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] SIPREC IETF83 - Draft Agenda Thread-Index: Acz+Ebv2NnpuKnMXTeiwf4SN9WYwuQAA223w References: <101C6067BEC68246B0C3F6843BCCC1E312946BC6C1@MCHP058A.global-ad.net> From: "Henry Lum" To: "Hutton, Andrew" , X-OriginalArrivalTime: 09 Mar 2012 16:53:53.0743 (UTC) FILETIME=[35CF05F0:01CCFE15] Subject: Re: [siprec] SIPREC IETF83 - Draft Agenda X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 16:53:55 -0000 This looks good to me. Thanks Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: March-09-12 11:29 AM > To: siprec@ietf.org > Subject: [siprec] SIPREC IETF83 - Draft Agenda >=20 > Hi All, >=20 > I uploaded a draft agenda for the SIPREC session at IETF83 (See > http://www.ietf.org/proceedings/83/agenda/agenda-83-siprec.html). >=20 > Please can those listed as presenting let me know if they are ok with > the time allocated? >=20 > Comments and suggestions are most welcome. >=20 > Regards > Andy (SIPREC Co-Chair). > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pravindran@sonusnet.com Sun Mar 11 23:27:05 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6924C21F8593 for ; Sun, 11 Mar 2012 23:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAhAWMXacf7I for ; Sun, 11 Mar 2012 23:27:04 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id DCE0321F8592 for ; Sun, 11 Mar 2012 23:27:03 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q2C6RpgX028835; Mon, 12 Mar 2012 02:27:51 -0400 Received: from USMA-EX-HUB1.sonusnet.com ([66.203.90.16]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 02:27:01 -0400 Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 12 Mar 2012 02:27:11 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Mon, 12 Mar 2012 11:56:58 +0530 From: "Ravindran, Parthasarathi" To: "Hutton, Andrew" , "siprec@ietf.org" Thread-Topic: SIPREC IETF83 - Draft Agenda Thread-Index: Acz+Ebv2NnpuKnMXTeiwf4SN9WYwuQCB1kTA Date: Mon, 12 Mar 2012 06:27:08 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E1F95EF@inba-mail01.sonusnet.com> References: <101C6067BEC68246B0C3F6843BCCC1E312946BC6C1@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312946BC6C1@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Mar 2012 06:27:01.0335 (UTC) FILETIME=[224E4670:01CD0019] Subject: Re: [siprec] SIPREC IETF83 - Draft Agenda X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 06:27:05 -0000 Andy, Thanks for the allocated SIPREC metadata timing. Thanks Partha >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Hutton, Andrew >Sent: Friday, March 09, 2012 9:59 PM >To: siprec@ietf.org >Subject: [siprec] SIPREC IETF83 - Draft Agenda > >Hi All, > >I uploaded a draft agenda for the SIPREC session at IETF83 (See >http://www.ietf.org/proceedings/83/agenda/agenda-83-siprec.html). > >Please can those listed as presenting let me know if they are ok with >the time allocated? > >Comments and suggestions are most welcome. > >Regards >Andy (SIPREC Co-Chair). >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From finlay.fraser@bt.com Mon Mar 12 06:12:05 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83E221F870B for ; Mon, 12 Mar 2012 06:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOEY6+OH6e6X for ; Mon, 12 Mar 2012 06:12:04 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD4721F86DC for ; Mon, 12 Mar 2012 06:12:03 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 12 Mar 2012 13:12:01 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.196]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Mon, 12 Mar 2012 13:12:01 +0000 From: To: , Date: Mon, 12 Mar 2012 13:11:59 +0000 Thread-Topic: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream Thread-Index: Acz7H+utWOk0o6HnS5mpHa+/rKi9XACxTO0wAAftmM0Akv4zAA== Message-ID: <67DAF295CD01EB44AE6EA8A51F6ABF0A408C796E81@EMV62-UKRD.domain1.systemhost.net> References: , <4F4E43D3.8070508@alum.mit.edu> , <387F9047F55E8C42850AD6B3A7A03C6C0E068E45@inba-mail01.sonusnet.com> , <4F4FB6EA.8050203@alum.mit.edu> <4F553F1C.9070400@alum.mit.edu>, <101C6067BEC68246B0C3F6843BCCC1E312946BC5E3@MCHP058A.global-ad.net> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: siprec@ietf.org Subject: Re: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 13:12:05 -0000 Andrew As a bit of background to this Trading turrets can have between 1 and 28 au= dio streams coming into them all of them require recording. To reduce recording costs trading companies have mixed devices to reduce VR= license costs, network bandwidth, Storage Typically there would be two han= dsets and 8 speakers mixed 2 :1 and 2 x 4:1 respectively. So in SIPREC we have one RS for a Turret which in the example above can hav= e 10 active CS these are being sent as 3 RTP streams or 3 m-lines to the re= coding capture devices. The compliance officers in the bank have accepted the mixing so there is no= requirement for the voice recorder to unmix the received streams they are = stored and tagged. Normally the recorder is also taking a CTI feed and it j= ust matches the tag normally a timestamp to the audio file in a many to one= arrangement. I hope this makes things a bit clearer Finlay ________________________________________ From: Hutton, Andrew [andrew.hutton@siemens-enterprise.com] Sent: 09 March 2012 14:40 To: Stafford,J,John,JRJ3X C Cc: siprec@ietf.org; Paul Kyzivat Subject: RE: [siprec] How to specify in metadata that multiple CS's are bei= ng recorded in a single mixed RS m line stream Hi John, I am also struggling to understand this use case. If you mean that you want to have the SRC act as an RTP Mixer and mix the s= treams from different CS's in to a single RTP Session using the CSRC to dem= ultiplex at the SRS then I think this is not supported by the current metad= ata model. Could our metadata experts please confirm? Regards Andy > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Paul Kyzivat > Sent: 05 March 2012 22:33 > To: john.2.stafford@bt.com > Cc: siprec@ietf.org > Subject: Re: [siprec] How to specify in metadata that multiple CS's=20 > are being recorded in a single mixed RS m line stream > > On 3/5/12 11:45 AM, john.2.stafford@bt.com wrote: > > Ok, CSG is not a concern. > > > > What I wanted clarified was how metadatas and would look=20 > > when > you have two simultaneous calls on an endpoint and both calls are=20 > mixed into a single recorder stream. > > > > If represents the mixed stream of two calls going to the > recorder, then how can a participant have a that references=20 > that stream, > > as a participant does NOT recv the mixed stream. > > I don't understand how it makes sense to mix the media for two=20 > distinct calls. > > Or do you mean that you want to send them both over a single RTP=20 > session, distinguished by SSRC or CSRC? > > Thanks, > Paul > > > > > Rgds > > John Stafford | Solution Architect 1 | BT Global Services=20 > > ________________________________________ > > From: Paul Kyzivat [pkyzivat@alum.mit.edu] > > Sent: 01 March 2012 17:50 > > To: Stafford,J,John,JRJ3X C > > Cc: pravindran@sonusnet.com; siprec@ietf.org > > Subject: Re: [siprec] How to specify in metadata that multiple CS's > are being recorded in a single mixed RS m line stream > > > > On 3/1/12 3:53 AM, john.2.stafford@bt.com wrote: > >> Partha, > >> > >> I cant see how using CSG will help with the describing of the > streams. > >> Also I'm not convinced this would be the correct usage of a CSG, as > while the calls are associated as they are made by the same person, in=20 > terms of sip they are completely unrelated. > >> I think draft-ietf-metadata could do with an explanation of what > relationships a CSG implies. > > > > Its your call whether these calls are related in a way that you want > to > > track as a CSG. > > > > Clearly there are a number of different reasons you might want to > group > > CSs, and we currently don't provide any attributes to distinguish=20 > > one reason from another. That is mostly because we didn't want to=20 > > get > into > > the business of enumerating the possible uses. The solution to that > is > > to add proprietary extension data to the CSG and/or the CSs to > identify > > why they are grouped. > > > > Alternatively I would simply treat these as two separate CSs, each > with > > a separate media stream. > > > > Thanks, > > Paul > > > >> Rgds > >> John Stafford | Solution Architect 1 | BT Global Services=20 > >> ________________________________________ > >> From: Ravindran, Parthasarathi [pravindran@sonusnet.com] > >> Sent: 01 March 2012 01:31 > >> To: Stafford,J,John,JRJ3X C; pkyzivat@alum.mit.edu; siprec@ietf.org > >> Subject: RE: [siprec] How to specify in metadata that multiple CS's > are being recorded in a single mixed RS m line stream > >> > >> John, > >> > >> I guess that you are looking for group (CSG) element usage. Person > AC sessions has to be grouped under single group. CS AC-B has to be=20 > mentioned as one of the session in group and CS AC-D has to be=20 > mentioned as another session of the group. Here, user AC is available=20 > in both sessions wherein participant (device) A is in session1 and=20 > participant (device) C is in session2, it is possible to pass=20 > participant name as AC in both sessions and it is perfectly fine. > Please let me know whether this approach solves your problem. > >> > >> Thanks > >> Partha > >> > >>> -----Original Message----- > >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > >>> Of john.2.stafford@bt.com > >>> Sent: Wednesday, February 29, 2012 11:36 PM > >>> To: pkyzivat@alum.mit.edu; siprec@ietf.org > >>> Subject: Re: [siprec] How to specify in metadata that multiple=20 > >>> CS's > are > >>> being recorded in a single mixed RS m line stream > >>> > >>> Paul, > >>> > >>> Its one person AC with two handsets both in use at same time, > probably > >>> one to each ear. > >>> > >>> Rgds > >>> John Stafford | Solution Architect 1 | BT Global Services=20 > >>> ________________________________________ > >>> From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf > Of > >>> Paul Kyzivat [pkyzivat@alum.mit.edu] > >>> Sent: 29 February 2012 15:27 > >>> To: siprec@ietf.org > >>> Subject: Re: [siprec] How to specify in metadata that multiple=20 > >>> CS's > are > >>> being recorded in a single mixed RS m line stream > >>> > >>> On 2/29/12 9:29 AM, john.2.stafford@bt.com wrote: > >>>> A converse of the "How to specify in metadata that a participants > >>> stream is being recorded in multiple m line streams" thread: > >>>> > >>>> Another of our record configurations is when a turret's handset=20 > >>>> 1 > and > >>>> handset 2 calls are recorded as a single mixed recorder stream > >>>> > >>>> once again a persistent RS will be set up at registration time,=20 > >>>> in > >>> this case there will be a single m line. > >>>> > >>>> So if represents a record stream, how would the > following be > >>> described in metadata: > >>>> > >>>> There are 2 calls, A-B and C-D, both are recorded via a single > >>> stream. > >>>> participants A and C are the same person, making two calls on > handset > >>> 1 and handset 2 of their turret. > >>> > >>> Just to clarify: > >>> > >>> There is one person, call him AC, that has two handsets A and C. > >>> AC has established one call with B (CS-A-B) and another call with=20 > >>> D > (CS- > >>> C-D). > >>> > >>> I gather these calls go on in parallel. (Maybe AC is switching=20 > >>> back > and > >>> forth taking into one handset of the other. In principal he could > put > >>> one to each ear and use both at the same time.) > >>> > >>> Or is this more like a two line phone, with radio buttons to=20 > >>> switch between the two lines, so that at any given time one is=20 > >>> active and > the > >>> other is "on hold"? > >>> > >>> I won't even try to respond to the stuff below until I get clarity > on > >>> the above. > >>> > >>> Thanks, > >>> Paul > >>> > >>>> The problems I have in describing this in metadata are: > >>>> 1. I dont know how to show what the participants, as they > dont > >>> recv the 2 call mixed stream. > >>>> 2. I only have a single stream being recorded which includes 2 > CS's, > >>>> but the element can only have a single session > attriibute > >>>> > >>>> I can only describe this using > >>> and. I have not been following the list > too > >>> closely for the past couple of months, is it still the intention=20 > >>> to > use > >>> these elements, as I see there is not yet a draft-ietf-metadata- > 06.txt > >>> that includes these elements in xml schema and examples. > >>>> > >>>> Also I dont know what happens to when using > >>> associations. > >>>> > >>>> Anyway, heres my stab at it, > >>>> > >>>> > >>>> > >>>> complete > >>>> > >>>> > >>>> >>>> id=3D"=3D=3DPARTICIPANT_A=3D=3D" > >>>> > >>>> RamMohan > R > >>>> > >>>> > >>>> >>>> participant=3D"=3D=3DPARTICIPANT_A=3D=3D" > >>>> session=3D"=3D=3D=3D=3DSESSION_ONE=3D=3D=3D=3D=3D= "> > >>>> 2010-12- > 16T23:41:07Z >>> time> > >>>> TBD > >>>> > >>>> >>>> participant=3D"=3D=3DPARTICIPANT_A=3D=3D" > >>>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> > >>>> 2010-12- > 16T23:41:07Z >>> time> > >>>> > >>>> > >>>> >>>> id=3D"=3D=3DPARTICIPANT_B=3D=3D" > >>>> > >>>> Paul > Kyzivat > >>>> > >>>> > >>>> >>>> participant=3D"=3D=3DPARTICIPANT_B=3D=3D" > >>>> session=3D"=3D=3D=3D=3DSESSION_ONE=3D=3D=3D=3D=3D= "> > >>>> 2010-12- > 16T23:41:07Z >>> time> > >>>> TBD > >>>> > >>>> >>>> participant=3D"=3D=3DPARTICIPANT_B=3D=3D" > >>>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> > >>>> 2010-12- > 16T23:41:07Z >>> time> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> >>>> id=3D"=3D=3DPARTICIPANT_C=3D=3D" > >>>> > >>>> RamMohan > R > >>>> > >>>> > >>>> >>>> participant=3D"=3D=3DPARTICIPANT_C=3D=3D" > >>>> session=3D"=3D=3D=3D=3DSESSION_TWO=3D=3D=3D=3D=3D= "> > >>>> 2010-12- > 16T22:02:04Z >>> time> > >>>> TBD > >>>> > >>>> >>>> participant=3D"=3D=3DPARTICIPANT_C=3D=3D" > >>>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> > >>>> 2010-12- > 16T22:02:04Z >>> time> > >>>> > >>>> > >>>> >>>> id=3D"=3D=3DPARTICIPANT_D=3D=3D" > >>>> > >>>> Andrew > >>> Hutton > >>>> > >>>> > >>>> >>>> participant=3D"=3D=3DPARTICIPANT_D=3D=3D" > >>>> session=3D"=3D=3D=3D=3DSESSION_TWO=3D=3D=3D=3D=3D= "> > >>>> 2010-12- > 16T22:02:04Z >>> time> > >>>> TBD > >>>> > >>>> >>>> participant=3D"=3D=3DPARTICIPANT_D=3D=3D" > >>>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> > >>>> 2010-12- > 16T22:02:04Z >>> time> > >>>> > >>>> > >>>> >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Rgds > >>>> John Stafford | Solution Architect 1 | BT Global Services=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 > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From internet-drafts@ietf.org Mon Mar 12 06:24:34 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD6921F86F6; Mon, 12 Mar 2012 06:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rh2tgqDLETLd; Mon, 12 Mar 2012 06:24:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A593421F86C3; Mon, 12 Mar 2012 06:24:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312132433.19581.40959.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 06:24:33 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 13:24:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Recording Working Group of the IE= TF. Title : An Architecture for Media Recording using the Session In= itiation Protocol Author(s) : Andrew Hutton Leon Portman Rajnish Jain Ken Rehor Filename : draft-ietf-siprec-architecture-04.txt Pages : 16 Date : 2012-03-12 Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes architectures for deploying session recording solutions in an environment which is based on the Session Initiation Protocol (SIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-siprec-architecture-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-architecture-04.txt From pkyzivat@alum.mit.edu Mon Mar 12 07:29:20 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4693721F8733 for ; Mon, 12 Mar 2012 07:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLVgdGAY3ajU for ; Mon, 12 Mar 2012 07:29:19 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 61D6E21F86F8 for ; Mon, 12 Mar 2012 07:29:19 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta13.westchester.pa.mail.comcast.net with comcast id ke9P1i00D1HzFnQ5DeVKT2; Mon, 12 Mar 2012 14:29:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta14.westchester.pa.mail.comcast.net with comcast id keVK1i00c07duvL3aeVK0P; Mon, 12 Mar 2012 14:29:19 +0000 Message-ID: <4F5E083E.5050501@alum.mit.edu> Date: Mon, 12 Mar 2012 10:29:18 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: , <4F4E43D3.8070508@alum.mit.edu> , <387F9047F55E8C42850AD6B3A7A03C6C0E068E45@inba-mail01.sonusnet.com> , <4F4FB6EA.8050203@alum.mit.edu> <4F553F1C.9070400@alum.mit.edu>, <101C6067BEC68246B0C3F6843BCCC1E312946BC5E3@MCHP058A.global-ad.net> <67DAF295CD01EB44AE6EA8A51F6ABF0A408C796E81@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <67DAF295CD01EB44AE6EA8A51F6ABF0A408C796E81@EMV62-UKRD.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 14:29:20 -0000 On 3/12/12 9:11 AM, finlay.fraser@bt.com wrote: > Andrew > > As a bit of background to this Trading turrets can have between 1 and 28 audio streams coming into them all of them require recording. > > To reduce recording costs trading companies have mixed devices to reduce VR license costs, network bandwidth, Storage Typically there would be two handsets and 8 speakers mixed 2 :1 and 2 x 4:1 respectively. > > So in SIPREC we have one RS for a Turret which in the example above can have 10 active CS these are being sent as 3 RTP streams or 3 m-lines to the recoding capture devices. > > The compliance officers in the bank have accepted the mixing so there is no requirement for the voice recorder to unmix the received streams they are stored and tagged. Normally the recorder is also taking a CTI feed and it just matches the tag normally a timestamp to the audio file in a many to one arrangement. > > I hope this makes things a bit clearer It *helps*, but I'm still confused as to the resulting streams contain. Can I assume that there is *one* Trader (T) participant be Turret? And then there could be 10 other participants, each in an independent CS with the Trader? (E.g. T:P0, ... T:P9). Is that right? And these are independent CS sessions in that T:Pi contains an exchange of media between T and Pi. Then you say these are then being mixed into some fewer number media sessions to the recorder. Is that done in a way that can be unraveled after the fact? (Say by SSRC or CSRC.) Thanks, Paul From finlay.fraser@bt.com Mon Mar 12 09:40:21 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A372B21E8012 for ; Mon, 12 Mar 2012 09:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+IemB3B9gVb for ; Mon, 12 Mar 2012 09:40:20 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id E662921E800E for ; Mon, 12 Mar 2012 09:40:19 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 12 Mar 2012 16:40:18 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.196]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Mon, 12 Mar 2012 16:40:18 +0000 From: To: , Date: Mon, 12 Mar 2012 16:40:17 +0000 Thread-Topic: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream Thread-Index: Acz7H+utWOk0o6HnS5mpHa+/rKi9XACxTO0wAAiuNgc= Message-ID: <67DAF295CD01EB44AE6EA8A51F6ABF0A408C436093@EMV62-UKRD.domain1.systemhost.net> References: , <4F4E43D3.8070508@alum.mit.edu> , <387F9047F55E8C42850AD6B3A7A03C6C0E068E45@inba-mail01.sonusnet.com> , <4F4FB6EA.8050203@alum.mit.edu> <4F553F1C.9070400@alum.mit.edu>, <101C6067BEC68246B0C3F6843BCCC1E312946BC5E3@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312946BC5E3@MCHP058A.global-ad.net> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: siprec@ietf.org Subject: Re: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 16:40:21 -0000 Guys As a bit of background to this Trading turrets can have between 1 and 28 au= dio streams coming into them all of them require recording. To reduce recording costs trading companies have mixed devices to reduce VR= license costs, network bandwidth, Storage Typically there would be two handsets and 8 speakers as follows:- Mix 1 - (Handset 1 RX and TX + Handset 2 RX and TX) Mix 2 - (Speaker 1 RX and TX + Speaker 2 RX and TX + Speaker 3 RX and TX + = Speaker 4 RX and TX) Mix 3 - (Speaker 5 RX and TX + Speaker 6 RX and TX + Speaker 7 RX and TX + = Speaker 8 RX and TX) So in SIPREC we have one RS for a Turret which in the example above can hav= e 10 active CS these are being sent as 3 RTP streams or 3 m-lines to the recoding capture devices. The compliance officers in the bank have accepted the mixing so there is no= requirement for the voice recorder to unmix the received streams they are = stored and tagged. Normally the recorder is also taking a CTI feed and it just mat= ches the tag normally a timestamp to the audio file in a many to one arrang= ement. I hope this makes things a bit clearer Finlay ________________________________________ From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of Hutton= , Andrew [andrew.hutton@siemens-enterprise.com] Sent: 09 March 2012 14:40 To: Stafford,J,John,JRJ3X C Cc: siprec@ietf.org Subject: Re: [siprec] How to specify in metadata that multiple CS's are bei= ng recorded in a single mixed RS m line stream Hi John, I am also struggling to understand this use case. If you mean that you want to have the SRC act as an RTP Mixer and mix the s= treams from different CS's in to a single RTP Session using the CSRC to dem= ultiplex at the SRS then I think this is not supported by the current metad= ata model. Could our metadata experts please confirm? Regards Andy > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 05 March 2012 22:33 > To: john.2.stafford@bt.com > Cc: siprec@ietf.org > Subject: Re: [siprec] How to specify in metadata that multiple CS's are > being recorded in a single mixed RS m line stream > > On 3/5/12 11:45 AM, john.2.stafford@bt.com wrote: > > Ok, CSG is not a concern. > > > > What I wanted clarified was how metadatas and would look when > you have two simultaneous calls on an endpoint and both calls are mixed > into a single recorder stream. > > > > If represents the mixed stream of two calls going to the > recorder, then how can a participant have a that references that > stream, > > as a participant does NOT recv the mixed stream. > > I don't understand how it makes sense to mix the media for two distinct > calls. > > Or do you mean that you want to send them both over a single RTP > session, distinguished by SSRC or CSRC? > > Thanks, > Paul > > > > > Rgds > > John Stafford | Solution Architect 1 | BT Global Services > > ________________________________________ > > From: Paul Kyzivat [pkyzivat@alum.mit.edu] > > Sent: 01 March 2012 17:50 > > To: Stafford,J,John,JRJ3X C > > Cc: pravindran@sonusnet.com; siprec@ietf.org > > Subject: Re: [siprec] How to specify in metadata that multiple CS's > are being recorded in a single mixed RS m line stream > > > > On 3/1/12 3:53 AM, john.2.stafford@bt.com wrote: > >> Partha, > >> > >> I cant see how using CSG will help with the describing of the > streams. > >> Also I'm not convinced this would be the correct usage of a CSG, as > while the calls are associated as they are made by the same person, in > terms of sip they are completely unrelated. > >> I think draft-ietf-metadata could do with an explanation of what > relationships a CSG implies. > > > > Its your call whether these calls are related in a way that you want > to > > track as a CSG. > > > > Clearly there are a number of different reasons you might want to > group > > CSs, and we currently don't provide any attributes to distinguish one > > reason from another. That is mostly because we didn't want to get > into > > the business of enumerating the possible uses. The solution to that > is > > to add proprietary extension data to the CSG and/or the CSs to > identify > > why they are grouped. > > > > Alternatively I would simply treat these as two separate CSs, each > with > > a separate media stream. > > > > Thanks, > > Paul > > > >> Rgds > >> John Stafford | Solution Architect 1 | BT Global Services > >> ________________________________________ > >> From: Ravindran, Parthasarathi [pravindran@sonusnet.com] > >> Sent: 01 March 2012 01:31 > >> To: Stafford,J,John,JRJ3X C; pkyzivat@alum.mit.edu; siprec@ietf.org > >> Subject: RE: [siprec] How to specify in metadata that multiple CS's > are being recorded in a single mixed RS m line stream > >> > >> John, > >> > >> I guess that you are looking for group (CSG) element usage. Person > AC sessions has to be grouped under single group. CS AC-B has to be > mentioned as one of the session in group and CS AC-D has to be > mentioned as another session of the group. Here, user AC is available > in both sessions wherein participant (device) A is in session1 and > participant (device) C is in session2, it is possible to pass > participant name as AC in both sessions and it is perfectly fine. > Please let me know whether this approach solves your problem. > >> > >> Thanks > >> Partha > >> > >>> -----Original Message----- > >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > >>> Of john.2.stafford@bt.com > >>> Sent: Wednesday, February 29, 2012 11:36 PM > >>> To: pkyzivat@alum.mit.edu; siprec@ietf.org > >>> Subject: Re: [siprec] How to specify in metadata that multiple CS's > are > >>> being recorded in a single mixed RS m line stream > >>> > >>> Paul, > >>> > >>> Its one person AC with two handsets both in use at same time, > probably > >>> one to each ear. > >>> > >>> Rgds > >>> John Stafford | Solution Architect 1 | BT Global Services > >>> ________________________________________ > >>> From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf > Of > >>> Paul Kyzivat [pkyzivat@alum.mit.edu] > >>> Sent: 29 February 2012 15:27 > >>> To: siprec@ietf.org > >>> Subject: Re: [siprec] How to specify in metadata that multiple CS's > are > >>> being recorded in a single mixed RS m line stream > >>> > >>> On 2/29/12 9:29 AM, john.2.stafford@bt.com wrote: > >>>> A converse of the "How to specify in metadata that a participants > >>> stream is being recorded in multiple m line streams" thread: > >>>> > >>>> Another of our record configurations is when a turret's handset 1 > and > >>>> handset 2 calls are recorded as a single mixed recorder stream > >>>> > >>>> once again a persistent RS will be set up at registration time, in > >>> this case there will be a single m line. > >>>> > >>>> So if represents a record stream, how would the > following be > >>> described in metadata: > >>>> > >>>> There are 2 calls, A-B and C-D, both are recorded via a single > >>> stream. > >>>> participants A and C are the same person, making two calls on > handset > >>> 1 and handset 2 of their turret. > >>> > >>> Just to clarify: > >>> > >>> There is one person, call him AC, that has two handsets A and C. > >>> AC has established one call with B (CS-A-B) and another call with D > (CS- > >>> C-D). > >>> > >>> I gather these calls go on in parallel. (Maybe AC is switching back > and > >>> forth taking into one handset of the other. In principal he could > put > >>> one to each ear and use both at the same time.) > >>> > >>> Or is this more like a two line phone, with radio buttons to switch > >>> between the two lines, so that at any given time one is active and > the > >>> other is "on hold"? > >>> > >>> I won't even try to respond to the stuff below until I get clarity > on > >>> the above. > >>> > >>> Thanks, > >>> Paul > >>> > >>>> The problems I have in describing this in metadata are: > >>>> 1. I dont know how to show what the participants, as they > dont > >>> recv the 2 call mixed stream. > >>>> 2. I only have a single stream being recorded which includes 2 > CS's, > >>>> but the element can only have a single session > attriibute > >>>> > >>>> I can only describe this using > >>> and. I have not been following the list > too > >>> closely for the past couple of months, is it still the intention to > use > >>> these elements, as I see there is not yet a draft-ietf-metadata- > 06.txt > >>> that includes these elements in xml schema and examples. > >>>> > >>>> Also I dont know what happens to when using > >>> associations. > >>>> > >>>> Anyway, heres my stab at it, > >>>> > >>>> > >>>> > >>>> complete > >>>> > >>>> > >>>> >>>> id=3D"=3D=3DPARTICIPANT_A=3D=3D" > >>>> > >>>> RamMohan > R > >>>> > >>>> > >>>> >>>> participant=3D"=3D=3DPARTICIPANT_A=3D=3D" > >>>> session=3D"=3D=3D=3D=3DSESSION_ONE=3D=3D=3D=3D=3D= "> > >>>> 2010-12- > 16T23:41:07Z >>> time> > >>>> TBD > >>>> > >>>> >>>> participant=3D"=3D=3DPARTICIPANT_A=3D=3D" > >>>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> > >>>> 2010-12- > 16T23:41:07Z >>> time> > >>>> > >>>> > >>>> >>>> id=3D"=3D=3DPARTICIPANT_B=3D=3D" > >>>> > >>>> Paul > Kyzivat > >>>> > >>>> > >>>> >>>> participant=3D"=3D=3DPARTICIPANT_B=3D=3D" > >>>> session=3D"=3D=3D=3D=3DSESSION_ONE=3D=3D=3D=3D=3D= "> > >>>> 2010-12- > 16T23:41:07Z >>> time> > >>>> TBD > >>>> > >>>> >>>> participant=3D"=3D=3DPARTICIPANT_B=3D=3D" > >>>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> > >>>> 2010-12- > 16T23:41:07Z >>> time> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> >>>> id=3D"=3D=3DPARTICIPANT_C=3D=3D" > >>>> > >>>> RamMohan > R > >>>> > >>>> > >>>> >>>> participant=3D"=3D=3DPARTICIPANT_C=3D=3D" > >>>> session=3D"=3D=3D=3D=3DSESSION_TWO=3D=3D=3D=3D=3D= "> > >>>> 2010-12- > 16T22:02:04Z >>> time> > >>>> TBD > >>>> > >>>> >>>> participant=3D"=3D=3DPARTICIPANT_C=3D=3D" > >>>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> > >>>> 2010-12- > 16T22:02:04Z >>> time> > >>>> > >>>> > >>>> >>>> id=3D"=3D=3DPARTICIPANT_D=3D=3D" > >>>> > >>>> Andrew > >>> Hutton > >>>> > >>>> > >>>> >>>> participant=3D"=3D=3DPARTICIPANT_D=3D=3D" > >>>> session=3D"=3D=3D=3D=3DSESSION_TWO=3D=3D=3D=3D=3D= "> > >>>> 2010-12- > 16T22:02:04Z >>> time> > >>>> TBD > >>>> > >>>> >>>> participant=3D"=3D=3DPARTICIPANT_D=3D=3D" > >>>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> > >>>> 2010-12- > 16T22:02:04Z >>> time> > >>>> > >>>> > >>>> >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Rgds > >>>> John Stafford | Solution Architect 1 | BT Global Services > >>>> _______________________________________________ > >>>> 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 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From internet-drafts@ietf.org Mon Mar 12 09:59:15 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33C021F8845; Mon, 12 Mar 2012 09:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVem6pLUIEP9; Mon, 12 Mar 2012 09:59:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAA421F87B7; Mon, 12 Mar 2012 09:59:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312165912.1431.16165.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 09:59:12 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-06.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 16:59:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Recording Working Group of the IE= TF. Title : Session Initiation Protocol (SIP) Recording Metadata Author(s) : Ram Mohan Ravindranath Parthasarathi Ravindran Paul Kyzivat Filename : draft-ietf-siprec-metadata-06.txt Pages : 48 Date : 2012-03-12 Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes the metadata model as viewed by Session Recording Server(SRS) and the Recording metadata format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-siprec-metadata-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-metadata-06.txt From pkyzivat@alum.mit.edu Mon Mar 12 10:00:55 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C5B21F8887 for ; Mon, 12 Mar 2012 10:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlqYMzguVwCA for ; Mon, 12 Mar 2012 10:00:54 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 515C221F8883 for ; Mon, 12 Mar 2012 10:00:54 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta03.westchester.pa.mail.comcast.net with comcast id keBA1i0051vXlb853h0scP; Mon, 12 Mar 2012 17:00:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta17.westchester.pa.mail.comcast.net with comcast id kh0s1i00T07duvL3dh0sfw; Mon, 12 Mar 2012 17:00:52 +0000 Message-ID: <4F5E2BC2.8060708@alum.mit.edu> Date: Mon, 12 Mar 2012 13:00:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: , <4F4E43D3.8070508@alum.mit.edu> , <387F9047F55E8C42850AD6B3A7A03C6C0E068E45@inba-mail01.sonusnet.com> , <4F4FB6EA.8050203@alum.mit.edu> <4F553F1C.9070400@alum.mit.edu>, <101C6067BEC68246B0C3F6843BCCC1E312946BC5E3@MCHP058A.global-ad.net> <67DAF295CD01EB44AE6EA8A51F6ABF0A408C436093@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <67DAF295CD01EB44AE6EA8A51F6ABF0A408C436093@EMV62-UKRD.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 17:00:56 -0000 On 3/12/12 12:40 PM, finlay.fraser@bt.com wrote: > Guys > > As a bit of background to this Trading turrets can have between 1 and 28 audio streams coming into them all of them require recording. > > To reduce recording costs trading companies have mixed devices to reduce VR license costs, network bandwidth, Storage > > Typically there would be two handsets and 8 speakers as follows:- > > Mix 1 - (Handset 1 RX and TX + Handset 2 RX and TX) > Mix 2 - (Speaker 1 RX and TX + Speaker 2 RX and TX + Speaker 3 RX and TX + Speaker 4 RX and TX) > Mix 3 - (Speaker 5 RX and TX + Speaker 6 RX and TX + Speaker 7 RX and TX + Speaker 8 RX and TX) First, can we clarify the terminology? I guess Handset 1 and 2 refer to handsets used by the Trader? And "Speaker" doesn't mean "loudspeaker", but rather designates a participant connected to the Trader? So there are 8 CSs, each involving the Trader and one of the Speakers? And each Speaker can hear only the Trader, not any of the other Speakers? (Ignoring unintended crosstalk.) Is each CS connected uniquely to one of the handsets? Or can either handset be connected to any of the Speakers? Do Mix 2 and Mix 3 assume that only one of the speakers in the mix is active at any one time? > So in SIPREC we have one RS for a Turret which in the example above can have 10 active CS these are being sent as 3 RTP streams > or 3 m-lines to the recoding capture devices. > > The compliance officers in the bank have accepted the mixing so there is no requirement for the voice recorder to unmix the received streams they are stored > and tagged. Normally the recorder is also taking a CTI feed and it just matches the tag normally a timestamp to the audio file in a many to one arrangement. Is there sufficient info in these mixes that the audio for each end of any one CS can be accurately reconstructed? (Even though there is no requirement that this be done? Thanks, Paul > I hope this makes things a bit clearer > > Finlay > ________________________________________ > From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of Hutton, Andrew [andrew.hutton@siemens-enterprise.com] > Sent: 09 March 2012 14:40 > To: Stafford,J,John,JRJ3X C > Cc: siprec@ietf.org > Subject: Re: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream > > Hi John, > > I am also struggling to understand this use case. > > If you mean that you want to have the SRC act as an RTP Mixer and mix the streams from different CS's in to a single RTP Session using the CSRC to demultiplex at the SRS then I think this is not supported by the current metadata model. > > Could our metadata experts please confirm? > > Regards > Andy > > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: 05 March 2012 22:33 >> To: john.2.stafford@bt.com >> Cc: siprec@ietf.org >> Subject: Re: [siprec] How to specify in metadata that multiple CS's are >> being recorded in a single mixed RS m line stream >> >> On 3/5/12 11:45 AM, john.2.stafford@bt.com wrote: >>> Ok, CSG is not a concern. >>> >>> What I wanted clarified was how metadatas and would look when >> you have two simultaneous calls on an endpoint and both calls are mixed >> into a single recorder stream. >>> >>> If represents the mixed stream of two calls going to the >> recorder, then how can a participant have a that references that >> stream, >>> as a participant does NOT recv the mixed stream. >> >> I don't understand how it makes sense to mix the media for two distinct >> calls. >> >> Or do you mean that you want to send them both over a single RTP >> session, distinguished by SSRC or CSRC? >> >> Thanks, >> Paul >> >>> >>> Rgds >>> John Stafford | Solution Architect 1 | BT Global Services >>> ________________________________________ >>> From: Paul Kyzivat [pkyzivat@alum.mit.edu] >>> Sent: 01 March 2012 17:50 >>> To: Stafford,J,John,JRJ3X C >>> Cc: pravindran@sonusnet.com; siprec@ietf.org >>> Subject: Re: [siprec] How to specify in metadata that multiple CS's >> are being recorded in a single mixed RS m line stream >>> >>> On 3/1/12 3:53 AM, john.2.stafford@bt.com wrote: >>>> Partha, >>>> >>>> I cant see how using CSG will help with the describing of the >> streams. >>>> Also I'm not convinced this would be the correct usage of a CSG, as >> while the calls are associated as they are made by the same person, in >> terms of sip they are completely unrelated. >>>> I think draft-ietf-metadata could do with an explanation of what >> relationships a CSG implies. >>> >>> Its your call whether these calls are related in a way that you want >> to >>> track as a CSG. >>> >>> Clearly there are a number of different reasons you might want to >> group >>> CSs, and we currently don't provide any attributes to distinguish one >>> reason from another. That is mostly because we didn't want to get >> into >>> the business of enumerating the possible uses. The solution to that >> is >>> to add proprietary extension data to the CSG and/or the CSs to >> identify >>> why they are grouped. >>> >>> Alternatively I would simply treat these as two separate CSs, each >> with >>> a separate media stream. >>> >>> Thanks, >>> Paul >>> >>>> Rgds >>>> John Stafford | Solution Architect 1 | BT Global Services >>>> ________________________________________ >>>> From: Ravindran, Parthasarathi [pravindran@sonusnet.com] >>>> Sent: 01 March 2012 01:31 >>>> To: Stafford,J,John,JRJ3X C; pkyzivat@alum.mit.edu; siprec@ietf.org >>>> Subject: RE: [siprec] How to specify in metadata that multiple CS's >> are being recorded in a single mixed RS m line stream >>>> >>>> John, >>>> >>>> I guess that you are looking for group (CSG) element usage. Person >> AC sessions has to be grouped under single group. CS AC-B has to be >> mentioned as one of the session in group and CS AC-D has to be >> mentioned as another session of the group. Here, user AC is available >> in both sessions wherein participant (device) A is in session1 and >> participant (device) C is in session2, it is possible to pass >> participant name as AC in both sessions and it is perfectly fine. >> Please let me know whether this approach solves your problem. >>>> >>>> Thanks >>>> Partha >>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf >>>>> Of john.2.stafford@bt.com >>>>> Sent: Wednesday, February 29, 2012 11:36 PM >>>>> To: pkyzivat@alum.mit.edu; siprec@ietf.org >>>>> Subject: Re: [siprec] How to specify in metadata that multiple CS's >> are >>>>> being recorded in a single mixed RS m line stream >>>>> >>>>> Paul, >>>>> >>>>> Its one person AC with two handsets both in use at same time, >> probably >>>>> one to each ear. >>>>> >>>>> Rgds >>>>> John Stafford | Solution Architect 1 | BT Global Services >>>>> ________________________________________ >>>>> From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf >> Of >>>>> Paul Kyzivat [pkyzivat@alum.mit.edu] >>>>> Sent: 29 February 2012 15:27 >>>>> To: siprec@ietf.org >>>>> Subject: Re: [siprec] How to specify in metadata that multiple CS's >> are >>>>> being recorded in a single mixed RS m line stream >>>>> >>>>> On 2/29/12 9:29 AM, john.2.stafford@bt.com wrote: >>>>>> A converse of the "How to specify in metadata that a participants >>>>> stream is being recorded in multiple m line streams" thread: >>>>>> >>>>>> Another of our record configurations is when a turret's handset 1 >> and >>>>>> handset 2 calls are recorded as a single mixed recorder stream >>>>>> >>>>>> once again a persistent RS will be set up at registration time, in >>>>> this case there will be a single m line. >>>>>> >>>>>> So if represents a record stream, how would the >> following be >>>>> described in metadata: >>>>>> >>>>>> There are 2 calls, A-B and C-D, both are recorded via a single >>>>> stream. >>>>>> participants A and C are the same person, making two calls on >> handset >>>>> 1 and handset 2 of their turret. >>>>> >>>>> Just to clarify: >>>>> >>>>> There is one person, call him AC, that has two handsets A and C. >>>>> AC has established one call with B (CS-A-B) and another call with D >> (CS- >>>>> C-D). >>>>> >>>>> I gather these calls go on in parallel. (Maybe AC is switching back >> and >>>>> forth taking into one handset of the other. In principal he could >> put >>>>> one to each ear and use both at the same time.) >>>>> >>>>> Or is this more like a two line phone, with radio buttons to switch >>>>> between the two lines, so that at any given time one is active and >> the >>>>> other is "on hold"? >>>>> >>>>> I won't even try to respond to the stuff below until I get clarity >> on >>>>> the above. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> The problems I have in describing this in metadata are: >>>>>> 1. I dont know how to show what the participants, as they >> dont >>>>> recv the 2 call mixed stream. >>>>>> 2. I only have a single stream being recorded which includes 2 >> CS's, >>>>>> but the element can only have a single session >> attriibute >>>>>> >>>>>> I can only describe this using >>>>> and. I have not been following the list >> too >>>>> closely for the past couple of months, is it still the intention to >> use >>>>> these elements, as I see there is not yet a draft-ietf-metadata- >> 06.txt >>>>> that includes these elements in xml schema and examples. >>>>>> >>>>>> Also I dont know what happens to when using >>>>> associations. >>>>>> >>>>>> Anyway, heres my stab at it, >>>>>> >>>>>> >>>>>> >>>>>> complete >>>>>> >>>>>> >>>>>> >>>>> id="==PARTICIPANT_A==" >>>>>> >>>>>> RamMohan >> R >>>>>> >>>>>> >>>>>> >>>>> participant="==PARTICIPANT_A==" >>>>>> session="====SESSION_ONE====="> >>>>>> 2010-12- >> 16T23:41:07Z>>>> time> >>>>>> TBD >>>>>> >>>>>> >>>>> participant="==PARTICIPANT_A==" >>>>>> stream ="i1Pz3to5hGk8fuXl+PbwCw=="> >>>>>> 2010-12- >> 16T23:41:07Z>>>> time> >>>>>> >>>>>> >>>>>> >>>>> id="==PARTICIPANT_B==" >>>>>> >>>>>> Paul >> Kyzivat >>>>>> >>>>>> >>>>>> >>>>> participant="==PARTICIPANT_B==" >>>>>> session="====SESSION_ONE====="> >>>>>> 2010-12- >> 16T23:41:07Z>>>> time> >>>>>> TBD >>>>>> >>>>>> >>>>> participant="==PARTICIPANT_B==" >>>>>> stream ="i1Pz3to5hGk8fuXl+PbwCw=="> >>>>>> 2010-12- >> 16T23:41:07Z>>>> time> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> id="==PARTICIPANT_C==" >>>>>> >>>>>> RamMohan >> R >>>>>> >>>>>> >>>>>> >>>>> participant="==PARTICIPANT_C==" >>>>>> session="====SESSION_TWO====="> >>>>>> 2010-12- >> 16T22:02:04Z>>>> time> >>>>>> TBD >>>>>> >>>>>> >>>>> participant="==PARTICIPANT_C==" >>>>>> stream ="i1Pz3to5hGk8fuXl+PbwCw=="> >>>>>> 2010-12- >> 16T22:02:04Z>>>> time> >>>>>> >>>>>> >>>>>> >>>>> id="==PARTICIPANT_D==" >>>>>> >>>>>> Andrew >>>>> Hutton >>>>>> >>>>>> >>>>>> >>>>> participant="==PARTICIPANT_D==" >>>>>> session="====SESSION_TWO====="> >>>>>> 2010-12- >> 16T22:02:04Z>>>> time> >>>>>> TBD >>>>>> >>>>>> >>>>> participant="==PARTICIPANT_D==" >>>>>> stream ="i1Pz3to5hGk8fuXl+PbwCw=="> >>>>>> 2010-12- >> 16T22:02:04Z>>>> time> >>>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Rgds >>>>>> John Stafford | Solution Architect 1 | BT Global Services >>>>>> _______________________________________________ >>>>>> 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 > _______________________________________________ > 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 Mar 12 10:15:46 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C6521F8876 for ; Mon, 12 Mar 2012 10:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFtHIDlqvRNn for ; Mon, 12 Mar 2012 10:15:46 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id EEE6721F8871 for ; Mon, 12 Mar 2012 10:15:45 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id DC3151EB844D for ; Mon, 12 Mar 2012 18:15:43 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 12 Mar 2012 18:15:44 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Date: Mon, 12 Mar 2012 18:15:42 +0100 Thread-Topic: I-D Action: draft-ietf-siprec-metadata-06.txt Thread-Index: Ac0AcYHTWmy5JCmjRPSOEwjdygZYZwAAjhqQ Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31296783A1B@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] FW: I-D Action: draft-ietf-siprec-metadata-06.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 17:15:47 -0000 From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: 12 March 2012 16:59 To: i-d-announce@ietf.org Cc: siprec@ietf.org Subject: I-D Action: draft-ietf-siprec-metadata-06.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Recording Working Group of the IE= TF. Title : Session Initiation Protocol (SIP) Recording Metadata Author(s) : Ram Mohan Ravindranath Parthasarathi Ravindran Paul Kyzivat Filename : draft-ietf-siprec-metadata-06.txt Pages : 48 Date : 2012-03-12 Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes the metadata model as viewed by Session Recording Server(SRS) and the Recording metadata format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-siprec-metadata-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-metadata-06.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From john.2.stafford@bt.com Tue Mar 13 04:23:15 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE4021F879B for ; Tue, 13 Mar 2012 04:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, J_CHICKENPOX_61=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvgDEetsnUi0 for ; Tue, 13 Mar 2012 04:23:13 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 487BB21F871A for ; Tue, 13 Mar 2012 04:23:13 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 13 Mar 2012 11:23:11 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.101]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Tue, 13 Mar 2012 11:23:11 +0000 From: To: , Date: Tue, 13 Mar 2012 11:23:10 +0000 Thread-Topic: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream Thread-Index: Ac0AccyIvCQOahYwRhKWiCseF161jAAkPX+m Message-ID: References: , <4F4E43D3.8070508@alum.mit.edu> , <387F9047F55E8C42850AD6B3A7A03C6C0E068E45@inba-mail01.sonusnet.com> , <4F4FB6EA.8050203@alum.mit.edu> <4F553F1C.9070400@alum.mit.edu>, <101C6067BEC68246B0C3F6843BCCC1E312946BC5E3@MCHP058A.global-ad.net> <67DAF295CD01EB44AE6EA8A51F6ABF0A408C436093@EMV62-UKRD.domain1.systemhost.net>, <4F5E2BC2.8060708@alum.mit.edu> In-Reply-To: <4F5E2BC2.8060708@alum.mit.edu> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 11:23:15 -0000 Paul, Ok let me have a go at explaining Finlay;s clarification! Handset 1 and Handset 2 are phone handsets, both work independantly like ha= ving 2 phones, but are both integrated into one turret. Speaker does mean loudspeaker, a trader can have many channels of audio he = is listening to simultaneously via loudspeakers, these channels need to be = recorded. However these are not receive only channels, the turret has a single stalk = microphone for talking back on the speaker channels. The trader can set the= microphone to be connected to one, or multiple speaker channels simultaneo= usly, and the mic can be always on or press to talk. So each handset and each of the speakers channels is a separate CS. The tra= der will be a participant in each CS. The recorded mixes do not have to be de-multiplexed, they rely on the human= ears ability to hear distinquish participants on replay, There is not sufficient information recorded to be able to de-multiplex the= audio mix for replay. In Finlays example where there are 8 speaker channels, they are as he shows= typically mixed 4:1 . They could also be mixed 2:1, in which case there would be 4 recorder strea= ms for the speakers, or even 8:1 giving just 1 record channel. The mix ratio is determined by how busy the channels are, ie if they are = stock prices which may be shouted on a channel maybe only one a minute the= n you could mix 8 channsla nd still expect on replay to be able to hear wha= t was being said. But if the channels have continuous commentary then you m= ay only be able to mix 2:1. It's a trade off of recorded/network bandwidth/cost against replay intellig= ibility. I think allowing a stream to have multiple session's (would have to be elem= ents not an attribute) would allow the recorded to find a mixed recorded CS= , but I am at a loss of what to do about the paticipants lement, as a= participant clearly does not recv the mixed stream. Hope that helps. Rgds John Stafford | Solution Architect 1 | BT Global Services | Tel:+44 (0)1932= 773504 | E: john.2.stafford@bt.com | www.bt.com/globalservices ________________________________________ From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of Paul K= yzivat [pkyzivat@alum.mit.edu] Sent: 12 March 2012 17:00 To: siprec@ietf.org Subject: Re: [siprec] How to specify in metadata that multiple CS's are bei= ng recorded in a single mixed RS m line stream On 3/12/12 12:40 PM, finlay.fraser@bt.com wrote: > Guys > > As a bit of background to this Trading turrets can have between 1 and 28 = audio streams coming into them all of them require recording. > > To reduce recording costs trading companies have mixed devices to reduce = VR license costs, network bandwidth, Storage > > Typically there would be two handsets and 8 speakers as follows:- > > Mix 1 - (Handset 1 RX and TX + Handset 2 RX and TX) > Mix 2 - (Speaker 1 RX and TX + Speaker 2 RX and TX + Speaker 3 RX and TX = + Speaker 4 RX and TX) > Mix 3 - (Speaker 5 RX and TX + Speaker 6 RX and TX + Speaker 7 RX and TX = + Speaker 8 RX and TX) First, can we clarify the terminology? I guess Handset 1 and 2 refer to handsets used by the Trader? And "Speaker" doesn't mean "loudspeaker", but rather designates a participant connected to the Trader? So there are 8 CSs, each involving the Trader and one of the Speakers? And each Speaker can hear only the Trader, not any of the other Speakers? (Ignoring unintended crosstalk.) Is each CS connected uniquely to one of the handsets? Or can either handset be connected to any of the Speakers? Do Mix 2 and Mix 3 assume that only one of the speakers in the mix is active at any one time? > So in SIPREC we have one RS for a Turret which in the example above can h= ave 10 active CS these are being sent as 3 RTP streams > or 3 m-lines to the recoding capture devices. > > The compliance officers in the bank have accepted the mixing so there is = no requirement for the voice recorder to unmix the received streams they ar= e stored > and tagged. Normally the recorder is also taking a CTI feed and it just m= atches the tag normally a timestamp to the audio file in a many to one arra= ngement. Is there sufficient info in these mixes that the audio for each end of any one CS can be accurately reconstructed? (Even though there is no requirement that this be done? Thanks, Paul > I hope this makes things a bit clearer > > Finlay > ________________________________________ > From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of Hutt= on, Andrew [andrew.hutton@siemens-enterprise.com] > Sent: 09 March 2012 14:40 > To: Stafford,J,John,JRJ3X C > Cc: siprec@ietf.org > Subject: Re: [siprec] How to specify in metadata that multiple CS's are b= eing recorded in a single mixed RS m line stream > > Hi John, > > I am also struggling to understand this use case. > > If you mean that you want to have the SRC act as an RTP Mixer and mix the= streams from different CS's in to a single RTP Session using the CSRC to d= emultiplex at the SRS then I think this is not supported by the current met= adata model. > > Could our metadata experts please confirm? > > Regards > Andy > > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: 05 March 2012 22:33 >> To: john.2.stafford@bt.com >> Cc: siprec@ietf.org >> Subject: Re: [siprec] How to specify in metadata that multiple CS's are >> being recorded in a single mixed RS m line stream >> >> On 3/5/12 11:45 AM, john.2.stafford@bt.com wrote: >>> Ok, CSG is not a concern. >>> >>> What I wanted clarified was how metadatas and would look when >> you have two simultaneous calls on an endpoint and both calls are mixed >> into a single recorder stream. >>> >>> If represents the mixed stream of two calls going to the >> recorder, then how can a participant have a that references that >> stream, >>> as a participant does NOT recv the mixed stream. >> >> I don't understand how it makes sense to mix the media for two distinct >> calls. >> >> Or do you mean that you want to send them both over a single RTP >> session, distinguished by SSRC or CSRC? >> >> Thanks, >> Paul >> >>> >>> Rgds >>> John Stafford | Solution Architect 1 | BT Global Services >>> ________________________________________ >>> From: Paul Kyzivat [pkyzivat@alum.mit.edu] >>> Sent: 01 March 2012 17:50 >>> To: Stafford,J,John,JRJ3X C >>> Cc: pravindran@sonusnet.com; siprec@ietf.org >>> Subject: Re: [siprec] How to specify in metadata that multiple CS's >> are being recorded in a single mixed RS m line stream >>> >>> On 3/1/12 3:53 AM, john.2.stafford@bt.com wrote: >>>> Partha, >>>> >>>> I cant see how using CSG will help with the describing of the >> streams. >>>> Also I'm not convinced this would be the correct usage of a CSG, as >> while the calls are associated as they are made by the same person, in >> terms of sip they are completely unrelated. >>>> I think draft-ietf-metadata could do with an explanation of what >> relationships a CSG implies. >>> >>> Its your call whether these calls are related in a way that you want >> to >>> track as a CSG. >>> >>> Clearly there are a number of different reasons you might want to >> group >>> CSs, and we currently don't provide any attributes to distinguish one >>> reason from another. That is mostly because we didn't want to get >> into >>> the business of enumerating the possible uses. The solution to that >> is >>> to add proprietary extension data to the CSG and/or the CSs to >> identify >>> why they are grouped. >>> >>> Alternatively I would simply treat these as two separate CSs, each >> with >>> a separate media stream. >>> >>> Thanks, >>> Paul >>> >>>> Rgds >>>> John Stafford | Solution Architect 1 | BT Global Services >>>> ________________________________________ >>>> From: Ravindran, Parthasarathi [pravindran@sonusnet.com] >>>> Sent: 01 March 2012 01:31 >>>> To: Stafford,J,John,JRJ3X C; pkyzivat@alum.mit.edu; siprec@ietf.org >>>> Subject: RE: [siprec] How to specify in metadata that multiple CS's >> are being recorded in a single mixed RS m line stream >>>> >>>> John, >>>> >>>> I guess that you are looking for group (CSG) element usage. Person >> AC sessions has to be grouped under single group. CS AC-B has to be >> mentioned as one of the session in group and CS AC-D has to be >> mentioned as another session of the group. Here, user AC is available >> in both sessions wherein participant (device) A is in session1 and >> participant (device) C is in session2, it is possible to pass >> participant name as AC in both sessions and it is perfectly fine. >> Please let me know whether this approach solves your problem. >>>> >>>> Thanks >>>> Partha >>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf >>>>> Of john.2.stafford@bt.com >>>>> Sent: Wednesday, February 29, 2012 11:36 PM >>>>> To: pkyzivat@alum.mit.edu; siprec@ietf.org >>>>> Subject: Re: [siprec] How to specify in metadata that multiple CS's >> are >>>>> being recorded in a single mixed RS m line stream >>>>> >>>>> Paul, >>>>> >>>>> Its one person AC with two handsets both in use at same time, >> probably >>>>> one to each ear. >>>>> >>>>> Rgds >>>>> John Stafford | Solution Architect 1 | BT Global Services >>>>> ________________________________________ >>>>> From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf >> Of >>>>> Paul Kyzivat [pkyzivat@alum.mit.edu] >>>>> Sent: 29 February 2012 15:27 >>>>> To: siprec@ietf.org >>>>> Subject: Re: [siprec] How to specify in metadata that multiple CS's >> are >>>>> being recorded in a single mixed RS m line stream >>>>> >>>>> On 2/29/12 9:29 AM, john.2.stafford@bt.com wrote: >>>>>> A converse of the "How to specify in metadata that a participants >>>>> stream is being recorded in multiple m line streams" thread: >>>>>> >>>>>> Another of our record configurations is when a turret's handset 1 >> and >>>>>> handset 2 calls are recorded as a single mixed recorder stream >>>>>> >>>>>> once again a persistent RS will be set up at registration time, in >>>>> this case there will be a single m line. >>>>>> >>>>>> So if represents a record stream, how would the >> following be >>>>> described in metadata: >>>>>> >>>>>> There are 2 calls, A-B and C-D, both are recorded via a single >>>>> stream. >>>>>> participants A and C are the same person, making two calls on >> handset >>>>> 1 and handset 2 of their turret. >>>>> >>>>> Just to clarify: >>>>> >>>>> There is one person, call him AC, that has two handsets A and C. >>>>> AC has established one call with B (CS-A-B) and another call with D >> (CS- >>>>> C-D). >>>>> >>>>> I gather these calls go on in parallel. (Maybe AC is switching back >> and >>>>> forth taking into one handset of the other. In principal he could >> put >>>>> one to each ear and use both at the same time.) >>>>> >>>>> Or is this more like a two line phone, with radio buttons to switch >>>>> between the two lines, so that at any given time one is active and >> the >>>>> other is "on hold"? >>>>> >>>>> I won't even try to respond to the stuff below until I get clarity >> on >>>>> the above. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> The problems I have in describing this in metadata are: >>>>>> 1. I dont know how to show what the participants, as they >> dont >>>>> recv the 2 call mixed stream. >>>>>> 2. I only have a single stream being recorded which includes 2 >> CS's, >>>>>> but the element can only have a single session >> attriibute >>>>>> >>>>>> I can only describe this using >>>>> and. I have not been following the list >> too >>>>> closely for the past couple of months, is it still the intention to >> use >>>>> these elements, as I see there is not yet a draft-ietf-metadata- >> 06.txt >>>>> that includes these elements in xml schema and examples. >>>>>> >>>>>> Also I dont know what happens to when using >>>>> associations. >>>>>> >>>>>> Anyway, heres my stab at it, >>>>>> >>>>>> >>>>>> >>>>>> complete >>>>>> >>>>>> >>>>>> >>>>> id=3D"=3D=3DPARTICIPANT_A=3D=3D" >>>>>> >>>>>> RamMohan >> R >>>>>> >>>>>> >>>>>> >>>>> participant=3D"=3D=3DPARTICIPANT_A=3D=3D" >>>>>> session=3D"=3D=3D=3D=3DSESSION_ONE=3D=3D=3D=3D= =3D"> >>>>>> 2010-12- >> 16T23:41:07Z>>>> time> >>>>>> TBD >>>>>> >>>>>> >>>>> participant=3D"=3D=3DPARTICIPANT_A=3D=3D" >>>>>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> >>>>>> 2010-12- >> 16T23:41:07Z>>>> time> >>>>>> >>>>>> >>>>>> >>>>> id=3D"=3D=3DPARTICIPANT_B=3D=3D" >>>>>> >>>>>> Paul >> Kyzivat >>>>>> >>>>>> >>>>>> >>>>> participant=3D"=3D=3DPARTICIPANT_B=3D=3D" >>>>>> session=3D"=3D=3D=3D=3DSESSION_ONE=3D=3D=3D=3D= =3D"> >>>>>> 2010-12- >> 16T23:41:07Z>>>> time> >>>>>> TBD >>>>>> >>>>>> >>>>> participant=3D"=3D=3DPARTICIPANT_B=3D=3D" >>>>>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> >>>>>> 2010-12- >> 16T23:41:07Z>>>> time> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> id=3D"=3D=3DPARTICIPANT_C=3D=3D" >>>>>> >>>>>> RamMohan >> R >>>>>> >>>>>> >>>>>> >>>>> participant=3D"=3D=3DPARTICIPANT_C=3D=3D" >>>>>> session=3D"=3D=3D=3D=3DSESSION_TWO=3D=3D=3D=3D= =3D"> >>>>>> 2010-12- >> 16T22:02:04Z>>>> time> >>>>>> TBD >>>>>> >>>>>> >>>>> participant=3D"=3D=3DPARTICIPANT_C=3D=3D" >>>>>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> >>>>>> 2010-12- >> 16T22:02:04Z>>>> time> >>>>>> >>>>>> >>>>>> >>>>> id=3D"=3D=3DPARTICIPANT_D=3D=3D" >>>>>> >>>>>> Andrew >>>>> Hutton >>>>>> >>>>>> >>>>>> >>>>> participant=3D"=3D=3DPARTICIPANT_D=3D=3D" >>>>>> session=3D"=3D=3D=3D=3DSESSION_TWO=3D=3D=3D=3D= =3D"> >>>>>> 2010-12- >> 16T22:02:04Z>>>> time> >>>>>> TBD >>>>>> >>>>>> >>>>> participant=3D"=3D=3DPARTICIPANT_D=3D=3D" >>>>>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> >>>>>> 2010-12- >> 16T22:02:04Z>>>> time> >>>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Rgds >>>>>> John Stafford | Solution Architect 1 | BT Global Services >>>>>> _______________________________________________ >>>>>> 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 > _______________________________________________ > 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 pravindran@sonusnet.com Tue Mar 13 04:49:32 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC1321F8717 for ; Tue, 13 Mar 2012 04:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[AWL=2.299, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tf7Hhd9iSX0e for ; Tue, 13 Mar 2012 04:49:31 -0700 (PDT) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with ESMTP id A60BF21F8707 for ; Tue, 13 Mar 2012 04:49:29 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKT180SbXDCrtJlQ3zkw7Wx6S1ejOx5N3y@postini.com; Tue, 13 Mar 2012 04:49:29 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 13 Mar 2012 06:12:18 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Tue, 13 Mar 2012 15:42:02 +0530 From: "Ravindran, Parthasarathi" To: "siprec@ietf.org" Thread-Topic: Change Summary & Review request: [siprec] I-D Action: draft-ietf-siprec-metadata-06.txt Thread-Index: AQHNAHGHTkSs3OZQN063X9j5w6ehZ5Zn/KQQ Date: Tue, 13 Mar 2012 10:12:01 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E1FBE81@inba-mail01.sonusnet.com> References: <20120312165912.1431.16165.idtracker@ietfa.amsl.com> In-Reply-To: <20120312165912.1431.16165.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Change Summary & Review request: I-D Action: draft-ietf-siprec-metadata-06.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 11:49:32 -0000 Hi all, IETF-82 SIPREC meeting consensus and other SIPREC mailing consensus after -= 05 revision of metadata draft are updated in this revision. Summary of chan= ges between -05 and -06 are as follows: 1) The association between participant and CS is changed as 0..* from 2..* 2) Associate-time and disassociate-time attributes in CS are moved to Parti= cipantCSAssociation 3) CSRSassociation metadata element creation to indicate the attributes rel= ated to CS and RS. 4) participantsessionassoc XML element is added to represent participant an= d session associated XML elements. 5) CSRC attribute is removed from participantstreamassociation object 6) ParticipantStreamAssoc XML element is introduced for association between= participant and stream XML element. 7) Sec 7 and Appendix B Example update based on new updated metadata XML Sc= hema 7) Proprietary unique-id usage is shown in Sec 7.1 example 8) XML schema update in Sec 8 based on metadata element changes Editorial changes 1) Added reference for reason header, p-asserted-identity 2) Changed RFC reference of RFCxxxx[RFCxxxx] to RFCxxxx 3) Changed *MUST* to MUST in Sec 6.5.3 Could you please review the updated metadata draft at http://www.ietf.org/i= nternet-drafts/draft-ietf-siprec-metadata-06.txt and provide your valuable = comments. Thanks Partha >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of internet-drafts@ietf.org >Sent: Monday, March 12, 2012 10:29 PM >To: i-d-announce@ietf.org >Cc: siprec@ietf.org >Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-06.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. This draft is a work item of the SIP Recording Working >Group of the IETF. > > Title : Session Initiation Protocol (SIP) Recording >Metadata > Author(s) : Ram Mohan Ravindranath > Parthasarathi Ravindran > Paul Kyzivat > Filename : draft-ietf-siprec-metadata-06.txt > Pages : 48 > Date : 2012-03-12 > > Session recording is a critical requirement in many communications > environments such as call centers and financial trading. In some of > these environments, all calls must be recorded for regulatory, > compliance, and consumer protection reasons. Recording of a session > is typically performed by sending a copy of a media stream to a > recording device. This document describes the metadata model as > viewed by Session Recording Server(SRS) and the Recording metadata > format. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-siprec-metadata-06.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >This Internet-Draft can be retrieved at: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-metadata-06.txt > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From Leon.Portman@nice.com Tue Mar 13 08:50:02 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6931721F8861 for ; Tue, 13 Mar 2012 08:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Da1VfSZBPHiS for ; Tue, 13 Mar 2012 08:50:01 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 50BBA21F8857 for ; Tue, 13 Mar 2012 08:50:01 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Tue, 13 Mar 2012 17:49:59 +0200 From: Leon Portman To: "siprec@ietf.org" Date: Tue, 13 Mar 2012 17:49:57 +0200 Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt Thread-Index: Ac0AU3wXDFTpfg8KQjar7VAIhq0WDQA3Klkg Message-ID: <07465C1D981ABC41A344374066AE1A2C39DAF8C0A7@TLVMBX01.nice.com> References: <20120312132433.19581.40959.idtracker@ietfa.amsl.com> In-Reply-To: <20120312132433.19581.40959.idtracker@ietfa.amsl.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] I-D Action: draft-ietf-siprec-architecture-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 15:50:02 -0000 Main changes. They are mainly consist from Gonzalo and other mailing lists = comments. 1. Definitions: Adding recording unaware UA definition and fixing some othe= r definitions 2. Consistent abbreviation usage in the document 3. Figures fixes 4. Adding policy mentions in Endpoint as SRC 5. Removing WEBRTC mentions 6. Adding more descriptions in SRS initiated flows 7.Adding support for RS without metadata There are some small typo mistakes in v04. I have already fixed them and wi= ll update in next version Regards Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= internet-drafts@ietf.org Sent: Monday, March 12, 2012 3:25 PM To: i-d-announce@ietf.org Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Recording Working Group of the IE= TF. Title : An Architecture for Media Recording using the Session In= itiation Protocol Author(s) : Andrew Hutton Leon Portman Rajnish Jain Ken Rehor Filename : draft-ietf-siprec-architecture-04.txt Pages : 16 Date : 2012-03-12 Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes architectures for deploying session recording solutions in an environment which is based on the Session Initiation Protocol (SIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-siprec-architecture-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-architecture-04.txt _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Tue Mar 13 08:50:59 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CA821F8861 for ; Tue, 13 Mar 2012 08:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_00=-2.599, J_CHICKENPOX_61=0.6, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tr9X2VicJIfg for ; Tue, 13 Mar 2012 08:50:58 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id C4EEB21F885C for ; Tue, 13 Mar 2012 08:50:57 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta12.westchester.pa.mail.comcast.net with comcast id l15i1i0041vXlb85C3qynp; Tue, 13 Mar 2012 15:50:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta17.westchester.pa.mail.comcast.net with comcast id l3qx1i01W07duvL3d3qylB; Tue, 13 Mar 2012 15:50:58 +0000 Message-ID: <4F5F6CDF.9040004@alum.mit.edu> Date: Tue, 13 Mar 2012 11:50:55 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: john.2.stafford@bt.com References: , <4F4E43D3.8070508@alum.mit.edu> , <387F9047F55E8C42850AD6B3A7A03C6C0E068E45@inba-mail01.sonusnet.com> , <4F4FB6EA.8050203@alum.mit.edu> <4F553F1C.9070400@alum.mit.edu>, <101C6067BEC68246B0C3F6843BCCC1E312946BC5E3@MCHP058A.global-ad.net> <67DAF295CD01EB44AE6EA8A51F6ABF0A408C436093@EMV62-UKRD.domain1.systemhost.net>, <4F5E2BC2.8060708@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 15:50:59 -0000 John, Thanks for the explanation. I think I now know more than I want to. :-) This is clearly a very specialized situation. One we certainly didn't contemplate in our definitions. Without further study and discussion I don't really know what the best way to map this is, or if there is a best way. My first reaction is to suggest that you map what you have onto our model the best you can - making this an application issue. (E.g. simply consider each of your mixes to be a CS with multiple participants.) If that doesn't work, and you feel that changes to the model would make it easier for you to map to, then certainly feel free to propose changes to the model. But if you do so, please propose something that makes sense in its own right, independent of your specialized application. Thanks, Paul On 3/13/12 7:23 AM, john.2.stafford@bt.com wrote: > Paul, > > Ok let me have a go at explaining Finlay;s clarification! > > Handset 1 and Handset 2 are phone handsets, both work independantly like having 2 phones, but are both integrated into one turret. > > Speaker does mean loudspeaker, a trader can have many channels of audio he is listening to simultaneously via loudspeakers, these channels need to be recorded. > However these are not receive only channels, the turret has a single stalk microphone for talking back on the speaker channels. The trader can set the microphone to be connected to one, or multiple speaker channels simultaneously, and the mic can be always on or press to talk. > > So each handset and each of the speakers channels is a separate CS. The trader will be a participant in each CS. > > The recorded mixes do not have to be de-multiplexed, they rely on the human ears ability to hear distinquish participants on replay, > There is not sufficient information recorded to be able to de-multiplex the audio mix for replay. > > In Finlays example where there are 8 speaker channels, they are as he shows typically mixed 4:1 . > They could also be mixed 2:1, in which case there would be 4 recorder streams for the speakers, > or even 8:1 giving just 1 record channel. > > The mix ratio is determined by how busy the channels are, ie if they are stock prices which may be shouted on a channel maybe only one a minute then you could mix 8 channsla nd still expect on replay to be able to hear what was being said. But if the channels have continuous commentary then you may only be able to mix 2:1. > It's a trade off of recorded/network bandwidth/cost against replay intelligibility. > > > > I think allowing a stream to have multiple session's (would have to be elements not an attribute) would allow the recorded to find a mixed recorded CS, > but I am at a loss of what to do about the paticipants lement, as a participant clearly does not recv the mixed stream. > > Hope that helps. > > Rgds > John Stafford | Solution Architect 1 | BT Global Services | Tel:+44 (0)1932 773504 | E: john.2.stafford@bt.com | www.bt.com/globalservices > ________________________________________ > From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat [pkyzivat@alum.mit.edu] > Sent: 12 March 2012 17:00 > To: siprec@ietf.org > Subject: Re: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream > > On 3/12/12 12:40 PM, finlay.fraser@bt.com wrote: >> Guys >> >> As a bit of background to this Trading turrets can have between 1 and 28 audio streams coming into them all of them require recording. >> >> To reduce recording costs trading companies have mixed devices to reduce VR license costs, network bandwidth, Storage >> >> Typically there would be two handsets and 8 speakers as follows:- >> >> Mix 1 - (Handset 1 RX and TX + Handset 2 RX and TX) >> Mix 2 - (Speaker 1 RX and TX + Speaker 2 RX and TX + Speaker 3 RX and TX + Speaker 4 RX and TX) >> Mix 3 - (Speaker 5 RX and TX + Speaker 6 RX and TX + Speaker 7 RX and TX + Speaker 8 RX and TX) > > First, can we clarify the terminology? > I guess Handset 1 and 2 refer to handsets used by the Trader? > And "Speaker" doesn't mean "loudspeaker", but rather designates a > participant connected to the Trader? > So there are 8 CSs, each involving the Trader and one of the Speakers? > And each Speaker can hear only the Trader, not any of the other > Speakers? (Ignoring unintended crosstalk.) > > Is each CS connected uniquely to one of the handsets? > Or can either handset be connected to any of the Speakers? > > Do Mix 2 and Mix 3 assume that only one of the speakers in the mix is > active at any one time? > >> So in SIPREC we have one RS for a Turret which in the example above can have 10 active CS these are being sent as 3 RTP streams >> or 3 m-lines to the recoding capture devices. >> >> The compliance officers in the bank have accepted the mixing so there is no requirement for the voice recorder to unmix the received streams they are stored >> and tagged. Normally the recorder is also taking a CTI feed and it just matches the tag normally a timestamp to the audio file in a many to one arrangement. > > Is there sufficient info in these mixes that the audio for each end of > any one CS can be accurately reconstructed? (Even though there is no > requirement that this be done? > > Thanks, > Paul > >> I hope this makes things a bit clearer >> >> Finlay >> ________________________________________ >> From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of Hutton, Andrew [andrew.hutton@siemens-enterprise.com] >> Sent: 09 March 2012 14:40 >> To: Stafford,J,John,JRJ3X C >> Cc: siprec@ietf.org >> Subject: Re: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream >> >> Hi John, >> >> I am also struggling to understand this use case. >> >> If you mean that you want to have the SRC act as an RTP Mixer and mix the streams from different CS's in to a single RTP Session using the CSRC to demultiplex at the SRS then I think this is not supported by the current metadata model. >> >> Could our metadata experts please confirm? >> >> Regards >> Andy >> >> >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: 05 March 2012 22:33 >>> To: john.2.stafford@bt.com >>> Cc: siprec@ietf.org >>> Subject: Re: [siprec] How to specify in metadata that multiple CS's are >>> being recorded in a single mixed RS m line stream >>> >>> On 3/5/12 11:45 AM, john.2.stafford@bt.com wrote: >>>> Ok, CSG is not a concern. >>>> >>>> What I wanted clarified was how metadatas and would look when >>> you have two simultaneous calls on an endpoint and both calls are mixed >>> into a single recorder stream. >>>> >>>> If represents the mixed stream of two calls going to the >>> recorder, then how can a participant have a that references that >>> stream, >>>> as a participant does NOT recv the mixed stream. >>> >>> I don't understand how it makes sense to mix the media for two distinct >>> calls. >>> >>> Or do you mean that you want to send them both over a single RTP >>> session, distinguished by SSRC or CSRC? >>> >>> Thanks, >>> Paul >>> >>>> >>>> Rgds >>>> John Stafford | Solution Architect 1 | BT Global Services >>>> ________________________________________ >>>> From: Paul Kyzivat [pkyzivat@alum.mit.edu] >>>> Sent: 01 March 2012 17:50 >>>> To: Stafford,J,John,JRJ3X C >>>> Cc: pravindran@sonusnet.com; siprec@ietf.org >>>> Subject: Re: [siprec] How to specify in metadata that multiple CS's >>> are being recorded in a single mixed RS m line stream >>>> >>>> On 3/1/12 3:53 AM, john.2.stafford@bt.com wrote: >>>>> Partha, >>>>> >>>>> I cant see how using CSG will help with the describing of the >>> streams. >>>>> Also I'm not convinced this would be the correct usage of a CSG, as >>> while the calls are associated as they are made by the same person, in >>> terms of sip they are completely unrelated. >>>>> I think draft-ietf-metadata could do with an explanation of what >>> relationships a CSG implies. >>>> >>>> Its your call whether these calls are related in a way that you want >>> to >>>> track as a CSG. >>>> >>>> Clearly there are a number of different reasons you might want to >>> group >>>> CSs, and we currently don't provide any attributes to distinguish one >>>> reason from another. That is mostly because we didn't want to get >>> into >>>> the business of enumerating the possible uses. The solution to that >>> is >>>> to add proprietary extension data to the CSG and/or the CSs to >>> identify >>>> why they are grouped. >>>> >>>> Alternatively I would simply treat these as two separate CSs, each >>> with >>>> a separate media stream. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Rgds >>>>> John Stafford | Solution Architect 1 | BT Global Services >>>>> ________________________________________ >>>>> From: Ravindran, Parthasarathi [pravindran@sonusnet.com] >>>>> Sent: 01 March 2012 01:31 >>>>> To: Stafford,J,John,JRJ3X C; pkyzivat@alum.mit.edu; siprec@ietf.org >>>>> Subject: RE: [siprec] How to specify in metadata that multiple CS's >>> are being recorded in a single mixed RS m line stream >>>>> >>>>> John, >>>>> >>>>> I guess that you are looking for group (CSG) element usage. Person >>> AC sessions has to be grouped under single group. CS AC-B has to be >>> mentioned as one of the session in group and CS AC-D has to be >>> mentioned as another session of the group. Here, user AC is available >>> in both sessions wherein participant (device) A is in session1 and >>> participant (device) C is in session2, it is possible to pass >>> participant name as AC in both sessions and it is perfectly fine. >>> Please let me know whether this approach solves your problem. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf >>>>>> Of john.2.stafford@bt.com >>>>>> Sent: Wednesday, February 29, 2012 11:36 PM >>>>>> To: pkyzivat@alum.mit.edu; siprec@ietf.org >>>>>> Subject: Re: [siprec] How to specify in metadata that multiple CS's >>> are >>>>>> being recorded in a single mixed RS m line stream >>>>>> >>>>>> Paul, >>>>>> >>>>>> Its one person AC with two handsets both in use at same time, >>> probably >>>>>> one to each ear. >>>>>> >>>>>> Rgds >>>>>> John Stafford | Solution Architect 1 | BT Global Services >>>>>> ________________________________________ >>>>>> From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf >>> Of >>>>>> Paul Kyzivat [pkyzivat@alum.mit.edu] >>>>>> Sent: 29 February 2012 15:27 >>>>>> To: siprec@ietf.org >>>>>> Subject: Re: [siprec] How to specify in metadata that multiple CS's >>> are >>>>>> being recorded in a single mixed RS m line stream >>>>>> >>>>>> On 2/29/12 9:29 AM, john.2.stafford@bt.com wrote: >>>>>>> A converse of the "How to specify in metadata that a participants >>>>>> stream is being recorded in multiple m line streams" thread: >>>>>>> >>>>>>> Another of our record configurations is when a turret's handset 1 >>> and >>>>>>> handset 2 calls are recorded as a single mixed recorder stream >>>>>>> >>>>>>> once again a persistent RS will be set up at registration time, in >>>>>> this case there will be a single m line. >>>>>>> >>>>>>> So if represents a record stream, how would the >>> following be >>>>>> described in metadata: >>>>>>> >>>>>>> There are 2 calls, A-B and C-D, both are recorded via a single >>>>>> stream. >>>>>>> participants A and C are the same person, making two calls on >>> handset >>>>>> 1 and handset 2 of their turret. >>>>>> >>>>>> Just to clarify: >>>>>> >>>>>> There is one person, call him AC, that has two handsets A and C. >>>>>> AC has established one call with B (CS-A-B) and another call with D >>> (CS- >>>>>> C-D). >>>>>> >>>>>> I gather these calls go on in parallel. (Maybe AC is switching back >>> and >>>>>> forth taking into one handset of the other. In principal he could >>> put >>>>>> one to each ear and use both at the same time.) >>>>>> >>>>>> Or is this more like a two line phone, with radio buttons to switch >>>>>> between the two lines, so that at any given time one is active and >>> the >>>>>> other is "on hold"? >>>>>> >>>>>> I won't even try to respond to the stuff below until I get clarity >>> on >>>>>> the above. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> The problems I have in describing this in metadata are: >>>>>>> 1. I dont know how to show what the participants, as they >>> dont >>>>>> recv the 2 call mixed stream. >>>>>>> 2. I only have a single stream being recorded which includes 2 >>> CS's, >>>>>>> but the element can only have a single session >>> attriibute >>>>>>> >>>>>>> I can only describe this using >>>>>> and. I have not been following the list >>> too >>>>>> closely for the past couple of months, is it still the intention to >>> use >>>>>> these elements, as I see there is not yet a draft-ietf-metadata- >>> 06.txt >>>>>> that includes these elements in xml schema and examples. >>>>>>> >>>>>>> Also I dont know what happens to when using >>>>>> associations. >>>>>>> >>>>>>> Anyway, heres my stab at it, >>>>>>> >>>>>>> >>>>>>> >>>>>>> complete >>>>>>> >>>>>>> >>>>>>> >>>>>> id="==PARTICIPANT_A==" >>>>>>> >>>>>>> RamMohan >>> R >>>>>>> >>>>>>> >>>>>>> >>>>>> participant="==PARTICIPANT_A==" >>>>>>> session="====SESSION_ONE====="> >>>>>>> 2010-12- >>> 16T23:41:07Z>>>>> time> >>>>>>> TBD >>>>>>> >>>>>>> >>>>>> participant="==PARTICIPANT_A==" >>>>>>> stream ="i1Pz3to5hGk8fuXl+PbwCw=="> >>>>>>> 2010-12- >>> 16T23:41:07Z>>>>> time> >>>>>>> >>>>>>> >>>>>>> >>>>>> id="==PARTICIPANT_B==" >>>>>>> >>>>>>> Paul >>> Kyzivat >>>>>>> >>>>>>> >>>>>>> >>>>>> participant="==PARTICIPANT_B==" >>>>>>> session="====SESSION_ONE====="> >>>>>>> 2010-12- >>> 16T23:41:07Z>>>>> time> >>>>>>> TBD >>>>>>> >>>>>>> >>>>>> participant="==PARTICIPANT_B==" >>>>>>> stream ="i1Pz3to5hGk8fuXl+PbwCw=="> >>>>>>> 2010-12- >>> 16T23:41:07Z>>>>> time> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> id="==PARTICIPANT_C==" >>>>>>> >>>>>>> RamMohan >>> R >>>>>>> >>>>>>> >>>>>>> >>>>>> participant="==PARTICIPANT_C==" >>>>>>> session="====SESSION_TWO====="> >>>>>>> 2010-12- >>> 16T22:02:04Z>>>>> time> >>>>>>> TBD >>>>>>> >>>>>>> >>>>>> participant="==PARTICIPANT_C==" >>>>>>> stream ="i1Pz3to5hGk8fuXl+PbwCw=="> >>>>>>> 2010-12- >>> 16T22:02:04Z>>>>> time> >>>>>>> >>>>>>> >>>>>>> >>>>>> id="==PARTICIPANT_D==" >>>>>>> >>>>>>> Andrew >>>>>> Hutton >>>>>>> >>>>>>> >>>>>>> >>>>>> participant="==PARTICIPANT_D==" >>>>>>> session="====SESSION_TWO====="> >>>>>>> 2010-12- >>> 16T22:02:04Z>>>>> time> >>>>>>> TBD >>>>>>> >>>>>>> >>>>>> participant="==PARTICIPANT_D==" >>>>>>> stream ="i1Pz3to5hGk8fuXl+PbwCw=="> >>>>>>> 2010-12- >>> 16T22:02:04Z>>>>> time> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Rgds >>>>>>> John Stafford | Solution Architect 1 | BT Global Services >>>>>>> _______________________________________________ >>>>>>> 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 >> _______________________________________________ >> 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 Tue Mar 13 09:49:34 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3CA21F87A7 for ; Tue, 13 Mar 2012 09:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[AWL=-0.507, BAYES_00=-2.599, J_CHICKENPOX_61=0.6, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFt4rO17eQ0w for ; Tue, 13 Mar 2012 09:49:32 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA8621E804E for ; Tue, 13 Mar 2012 09:49:32 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id DA61E1EB83FD; Tue, 13 Mar 2012 17:49:30 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 13 Mar 2012 17:49:30 +0100 From: "Hutton, Andrew" To: Paul Kyzivat , "john.2.stafford@bt.com" Date: Tue, 13 Mar 2012 17:49:28 +0100 Thread-Topic: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream Thread-Index: Ac0BMRfQmEj8FU95R5iZW+JziVR6fwABeiAg Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312967840E2@MCHP058A.global-ad.net> References: , <4F4E43D3.8070508@alum.mit.edu> , <387F9047F55E8C42850AD6B3A7A03C6C0E068E45@inba-mail01.sonusnet.com> , <4F4FB6EA.8050203@alum.mit.edu> <4F553F1C.9070400@alum.mit.edu>, <101C6067BEC68246B0C3F6843BCCC1E312946BC5E3@MCHP058A.global-ad.net> <67DAF295CD01EB44AE6EA8A51F6ABF0A408C436093@EMV62-UKRD.domain1.systemhost.net>, <4F5E2BC2.8060708@alum.mit.edu> <4F5F6CDF.9040004@alum.mit.edu> In-Reply-To: <4F5F6CDF.9040004@alum.mit.edu> 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] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 16:49:34 -0000 Hi John, I agree with Paul's conclusions below. If the current metadata model does not fit your requirements then I would e= ncourage you to make a proposal for changes to the metadata model and we ca= n then discuss the proposal in the working group. Will you be in the Paris meeting? Regards Andy > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 13 March 2012 15:51 > To: john.2.stafford@bt.com > Cc: siprec@ietf.org > Subject: Re: [siprec] How to specify in metadata that multiple CS's are > being recorded in a single mixed RS m line stream > > John, > > Thanks for the explanation. I think I now know more than I want to. :-) > This is clearly a very specialized situation. One we certainly didn't > contemplate in our definitions. Without further study and discussion I > don't really know what the best way to map this is, or if there is a > best way. > > My first reaction is to suggest that you map what you have onto our > model the best you can - making this an application issue. (E.g. simply > consider each of your mixes to be a CS with multiple participants.) > > If that doesn't work, and you feel that changes to the model would make > it easier for you to map to, then certainly feel free to propose > changes > to the model. But if you do so, please propose something that makes > sense in its own right, independent of your specialized application. > > Thanks, > Paul > > On 3/13/12 7:23 AM, john.2.stafford@bt.com wrote: > > Paul, > > > > Ok let me have a go at explaining Finlay;s clarification! > > > > Handset 1 and Handset 2 are phone handsets, both work independantly > like having 2 phones, but are both integrated into one turret. > > > > Speaker does mean loudspeaker, a trader can have many channels of > audio he is listening to simultaneously via loudspeakers, these > channels need to be recorded. > > However these are not receive only channels, the turret has a single > stalk microphone for talking back on the speaker channels. The trader > can set the microphone to be connected to one, or multiple speaker > channels simultaneously, and the mic can be always on or press to talk. > > > > So each handset and each of the speakers channels is a separate CS. > The trader will be a participant in each CS. > > > > The recorded mixes do not have to be de-multiplexed, they rely on the > human ears ability to hear distinquish participants on replay, > > There is not sufficient information recorded to be able to de- > multiplex the audio mix for replay. > > > > In Finlays example where there are 8 speaker channels, they are as he > shows typically mixed 4:1 . > > They could also be mixed 2:1, in which case there would be 4 recorder > streams for the speakers, > > or even 8:1 giving just 1 record channel. > > > > The mix ratio is determined by how busy the channels are, ie if they > are stock prices which may be shouted on a channel maybe only one a > minute then you could mix 8 channsla nd still expect on replay to be > able to hear what was being said. But if the channels have continuous > commentary then you may only be able to mix 2:1. > > It's a trade off of recorded/network bandwidth/cost against replay > intelligibility. > > > > > > > > I think allowing a stream to have multiple session's (would have to > be elements not an attribute) would allow the recorded to find a mixed > recorded CS, > > but I am at a loss of what to do about the paticipants > lement, as a participant clearly does not recv the mixed stream. > > > > Hope that helps. > > > > Rgds > > John Stafford | Solution Architect 1 | BT Global Services | Tel:+44 > (0)1932 773504 | E: john.2.stafford@bt.com | > www.bt.com/globalservices > > ________________________________________ > > From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of > Paul Kyzivat [pkyzivat@alum.mit.edu] > > Sent: 12 March 2012 17:00 > > To: siprec@ietf.org > > Subject: Re: [siprec] How to specify in metadata that multiple CS's > are being recorded in a single mixed RS m line stream > > > > On 3/12/12 12:40 PM, finlay.fraser@bt.com wrote: > >> Guys > >> > >> As a bit of background to this Trading turrets can have between 1 > and 28 audio streams coming into them all of them require recording. > >> > >> To reduce recording costs trading companies have mixed devices to > reduce VR license costs, network bandwidth, Storage > >> > >> Typically there would be two handsets and 8 speakers as follows:- > >> > >> Mix 1 - (Handset 1 RX and TX + Handset 2 RX and TX) > >> Mix 2 - (Speaker 1 RX and TX + Speaker 2 RX and TX + Speaker 3 RX > and TX + Speaker 4 RX and TX) > >> Mix 3 - (Speaker 5 RX and TX + Speaker 6 RX and TX + Speaker 7 RX > and TX + Speaker 8 RX and TX) > > > > First, can we clarify the terminology? > > I guess Handset 1 and 2 refer to handsets used by the Trader? > > And "Speaker" doesn't mean "loudspeaker", but rather designates a > > participant connected to the Trader? > > So there are 8 CSs, each involving the Trader and one of the > Speakers? > > And each Speaker can hear only the Trader, not any of the other > > Speakers? (Ignoring unintended crosstalk.) > > > > Is each CS connected uniquely to one of the handsets? > > Or can either handset be connected to any of the Speakers? > > > > Do Mix 2 and Mix 3 assume that only one of the speakers in the mix is > > active at any one time? > > > >> So in SIPREC we have one RS for a Turret which in the example above > can have 10 active CS these are being sent as 3 RTP streams > >> or 3 m-lines to the recoding capture devices. > >> > >> The compliance officers in the bank have accepted the mixing so > there is no requirement for the voice recorder to unmix the received > streams they are stored > >> and tagged. Normally the recorder is also taking a CTI feed and it > just matches the tag normally a timestamp to the audio file in a many > to one arrangement. > > > > Is there sufficient info in these mixes that the audio for each end > of > > any one CS can be accurately reconstructed? (Even though there is no > > requirement that this be done? > > > > Thanks, > > Paul > > > >> I hope this makes things a bit clearer > >> > >> Finlay > >> ________________________________________ > >> From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of > Hutton, Andrew [andrew.hutton@siemens-enterprise.com] > >> Sent: 09 March 2012 14:40 > >> To: Stafford,J,John,JRJ3X C > >> Cc: siprec@ietf.org > >> Subject: Re: [siprec] How to specify in metadata that multiple CS's > are being recorded in a single mixed RS m line stream > >> > >> Hi John, > >> > >> I am also struggling to understand this use case. > >> > >> If you mean that you want to have the SRC act as an RTP Mixer and > mix the streams from different CS's in to a single RTP Session using > the CSRC to demultiplex at the SRS then I think this is not supported > by the current metadata model. > >> > >> Could our metadata experts please confirm? > >> > >> Regards > >> Andy > >> > >> > >> > >>> -----Original Message----- > >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>> Behalf Of Paul Kyzivat > >>> Sent: 05 March 2012 22:33 > >>> To: john.2.stafford@bt.com > >>> Cc: siprec@ietf.org > >>> Subject: Re: [siprec] How to specify in metadata that multiple CS's > are > >>> being recorded in a single mixed RS m line stream > >>> > >>> On 3/5/12 11:45 AM, john.2.stafford@bt.com wrote: > >>>> Ok, CSG is not a concern. > >>>> > >>>> What I wanted clarified was how metadatas and would look > when > >>> you have two simultaneous calls on an endpoint and both calls are > mixed > >>> into a single recorder stream. > >>>> > >>>> If represents the mixed stream of two calls going to > the > >>> recorder, then how can a participant have a that > references that > >>> stream, > >>>> as a participant does NOT recv the mixed stream. > >>> > >>> I don't understand how it makes sense to mix the media for two > distinct > >>> calls. > >>> > >>> Or do you mean that you want to send them both over a single RTP > >>> session, distinguished by SSRC or CSRC? > >>> > >>> Thanks, > >>> Paul > >>> > >>>> > >>>> Rgds > >>>> John Stafford | Solution Architect 1 | BT Global Services > >>>> ________________________________________ > >>>> From: Paul Kyzivat [pkyzivat@alum.mit.edu] > >>>> Sent: 01 March 2012 17:50 > >>>> To: Stafford,J,John,JRJ3X C > >>>> Cc: pravindran@sonusnet.com; siprec@ietf.org > >>>> Subject: Re: [siprec] How to specify in metadata that multiple > CS's > >>> are being recorded in a single mixed RS m line stream > >>>> > >>>> On 3/1/12 3:53 AM, john.2.stafford@bt.com wrote: > >>>>> Partha, > >>>>> > >>>>> I cant see how using CSG will help with the describing of the > >>> streams. > >>>>> Also I'm not convinced this would be the correct usage of a CSG, > as > >>> while the calls are associated as they are made by the same person, > in > >>> terms of sip they are completely unrelated. > >>>>> I think draft-ietf-metadata could do with an explanation of what > >>> relationships a CSG implies. > >>>> > >>>> Its your call whether these calls are related in a way that you > want > >>> to > >>>> track as a CSG. > >>>> > >>>> Clearly there are a number of different reasons you might want to > >>> group > >>>> CSs, and we currently don't provide any attributes to distinguish > one > >>>> reason from another. That is mostly because we didn't want to get > >>> into > >>>> the business of enumerating the possible uses. The solution to > that > >>> is > >>>> to add proprietary extension data to the CSG and/or the CSs to > >>> identify > >>>> why they are grouped. > >>>> > >>>> Alternatively I would simply treat these as two separate CSs, each > >>> with > >>>> a separate media stream. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>> Rgds > >>>>> John Stafford | Solution Architect 1 | BT Global Services > >>>>> ________________________________________ > >>>>> From: Ravindran, Parthasarathi [pravindran@sonusnet.com] > >>>>> Sent: 01 March 2012 01:31 > >>>>> To: Stafford,J,John,JRJ3X C; pkyzivat@alum.mit.edu; > siprec@ietf.org > >>>>> Subject: RE: [siprec] How to specify in metadata that multiple > CS's > >>> are being recorded in a single mixed RS m line stream > >>>>> > >>>>> John, > >>>>> > >>>>> I guess that you are looking for group (CSG) element usage. > Person > >>> AC sessions has to be grouped under single group. CS AC-B has to be > >>> mentioned as one of the session in group and CS AC-D has to be > >>> mentioned as another session of the group. Here, user AC is > available > >>> in both sessions wherein participant (device) A is in session1 and > >>> participant (device) C is in session2, it is possible to pass > >>> participant name as AC in both sessions and it is perfectly fine. > >>> Please let me know whether this approach solves your problem. > >>>>> > >>>>> Thanks > >>>>> Partha > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > >>> Behalf > >>>>>> Of john.2.stafford@bt.com > >>>>>> Sent: Wednesday, February 29, 2012 11:36 PM > >>>>>> To: pkyzivat@alum.mit.edu; siprec@ietf.org > >>>>>> Subject: Re: [siprec] How to specify in metadata that multiple > CS's > >>> are > >>>>>> being recorded in a single mixed RS m line stream > >>>>>> > >>>>>> Paul, > >>>>>> > >>>>>> Its one person AC with two handsets both in use at same time, > >>> probably > >>>>>> one to each ear. > >>>>>> > >>>>>> Rgds > >>>>>> John Stafford | Solution Architect 1 | BT Global Services > >>>>>> ________________________________________ > >>>>>> From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On > Behalf > >>> Of > >>>>>> Paul Kyzivat [pkyzivat@alum.mit.edu] > >>>>>> Sent: 29 February 2012 15:27 > >>>>>> To: siprec@ietf.org > >>>>>> Subject: Re: [siprec] How to specify in metadata that multiple > CS's > >>> are > >>>>>> being recorded in a single mixed RS m line stream > >>>>>> > >>>>>> On 2/29/12 9:29 AM, john.2.stafford@bt.com wrote: > >>>>>>> A converse of the "How to specify in metadata that a > participants > >>>>>> stream is being recorded in multiple m line streams" thread: > >>>>>>> > >>>>>>> Another of our record configurations is when a turret's > handset 1 > >>> and > >>>>>>> handset 2 calls are recorded as a single mixed recorder stream > >>>>>>> > >>>>>>> once again a persistent RS will be set up at registration time, > in > >>>>>> this case there will be a single m line. > >>>>>>> > >>>>>>> So if represents a record stream, how would the > >>> following be > >>>>>> described in metadata: > >>>>>>> > >>>>>>> There are 2 calls, A-B and C-D, both are recorded via a single > >>>>>> stream. > >>>>>>> participants A and C are the same person, making two calls on > >>> handset > >>>>>> 1 and handset 2 of their turret. > >>>>>> > >>>>>> Just to clarify: > >>>>>> > >>>>>> There is one person, call him AC, that has two handsets A and C. > >>>>>> AC has established one call with B (CS-A-B) and another call > with D > >>> (CS- > >>>>>> C-D). > >>>>>> > >>>>>> I gather these calls go on in parallel. (Maybe AC is switching > back > >>> and > >>>>>> forth taking into one handset of the other. In principal he > could > >>> put > >>>>>> one to each ear and use both at the same time.) > >>>>>> > >>>>>> Or is this more like a two line phone, with radio buttons to > switch > >>>>>> between the two lines, so that at any given time one is active > and > >>> the > >>>>>> other is "on hold"? > >>>>>> > >>>>>> I won't even try to respond to the stuff below until I get > clarity > >>> on > >>>>>> the above. > >>>>>> > >>>>>> Thanks, > >>>>>> Paul > >>>>>> > >>>>>>> The problems I have in describing this in metadata are: > >>>>>>> 1. I dont know how to show what the participants, as they > >>> dont > >>>>>> recv the 2 call mixed stream. > >>>>>>> 2. I only have a single stream being recorded which includes 2 > >>> CS's, > >>>>>>> but the element can only have a single session > >>> attriibute > >>>>>>> > >>>>>>> I can only describe this using > >>>>>> and. I have not been following the > list > >>> too > >>>>>> closely for the past couple of months, is it still the intention > to > >>> use > >>>>>> these elements, as I see there is not yet a draft-ietf-metadata- > >>> 06.txt > >>>>>> that includes these elements in xml schema and examples. > >>>>>>> > >>>>>>> Also I dont know what happens to when > using > >>>>>> associations. > >>>>>>> > >>>>>>> Anyway, heres my stab at it, > >>>>>>> > >>>>>>> > >>>>>>> xmlns=3D'urn:ietf:params:xml:ns:recording'> > >>>>>>> complete > >>>>>>> > >>>>>>> > >>>>>>> >>>>>>> id=3D"=3D=3DPARTICIPANT_A=3D=3D" > >>>>>>> > >>>>>>> RamMohan > >>> R > >>>>>>> > >>>>>>> > >>>>>>> >>>>>>> participant=3D"=3D=3DPARTICIPANT_A=3D=3D" > >>>>>>> session=3D"=3D=3D=3D=3DSESSION_ONE=3D=3D=3D= =3D=3D"> > >>>>>>> 2010-12- > >>> 16T23:41:07Z >>>>>> time> > >>>>>>> TBD > >>>>>>> > >>>>>>> >>>>>>> participant=3D"=3D=3DPARTICIPANT_A=3D=3D" > >>>>>>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> > >>>>>>> 2010-12- > >>> 16T23:41:07Z >>>>>> time> > >>>>>>> > >>>>>>> > >>>>>>> >>>>>>> id=3D"=3D=3DPARTICIPANT_B=3D=3D" > >>>>>>> > >>>>>>> Paul > >>> Kyzivat > >>>>>>> > >>>>>>> > >>>>>>> >>>>>>> participant=3D"=3D=3DPARTICIPANT_B=3D=3D" > >>>>>>> session=3D"=3D=3D=3D=3DSESSION_ONE=3D=3D=3D= =3D=3D"> > >>>>>>> 2010-12- > >>> 16T23:41:07Z >>>>>> time> > >>>>>>> TBD > >>>>>>> > >>>>>>> >>>>>>> participant=3D"=3D=3DPARTICIPANT_B=3D=3D" > >>>>>>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> > >>>>>>> 2010-12- > >>> 16T23:41:07Z >>>>>> time> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> >>>>>>> id=3D"=3D=3DPARTICIPANT_C=3D=3D" > >>>>>>> > >>>>>>> RamMohan > >>> R > >>>>>>> > >>>>>>> > >>>>>>> >>>>>>> participant=3D"=3D=3DPARTICIPANT_C=3D=3D" > >>>>>>> session=3D"=3D=3D=3D=3DSESSION_TWO=3D=3D=3D= =3D=3D"> > >>>>>>> 2010-12- > >>> 16T22:02:04Z >>>>>> time> > >>>>>>> TBD > >>>>>>> > >>>>>>> >>>>>>> participant=3D"=3D=3DPARTICIPANT_C=3D=3D" > >>>>>>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> > >>>>>>> 2010-12- > >>> 16T22:02:04Z >>>>>> time> > >>>>>>> > >>>>>>> > >>>>>>> >>>>>>> id=3D"=3D=3DPARTICIPANT_D=3D=3D" > >>>>>>> > >>>>>>> Andrew > >>>>>> Hutton > >>>>>>> > >>>>>>> > >>>>>>> >>>>>>> participant=3D"=3D=3DPARTICIPANT_D=3D=3D" > >>>>>>> session=3D"=3D=3D=3D=3DSESSION_TWO=3D=3D=3D= =3D=3D"> > >>>>>>> 2010-12- > >>> 16T22:02:04Z >>>>>> time> > >>>>>>> TBD > >>>>>>> > >>>>>>> >>>>>>> participant=3D"=3D=3DPARTICIPANT_D=3D=3D" > >>>>>>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> > >>>>>>> 2010-12- > >>> 16T22:02:04Z >>>>>> time> > >>>>>>> > >>>>>>> > >>>>>>> >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Rgds > >>>>>>> John Stafford | Solution Architect 1 | BT Global Services > >>>>>>> _______________________________________________ > >>>>>>> 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 > >> _______________________________________________ > >> 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.2.stafford@bt.com Tue Mar 13 10:22:49 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F3821E8049 for ; Tue, 13 Mar 2012 10:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.259 X-Spam-Level: X-Spam-Status: No, score=-3.259 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiw5U7rGFQiJ for ; Tue, 13 Mar 2012 10:22:47 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 7128121E8045 for ; Tue, 13 Mar 2012 10:22:47 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 13 Mar 2012 17:22:46 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.101]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Tue, 13 Mar 2012 17:22:46 +0000 From: To: , Date: Tue, 13 Mar 2012 17:22:45 +0000 Thread-Topic: [siprec] Change Summary & Review request: I-D Action: draft-ietf-siprec-metadata-06.txt Thread-Index: AQHNAHGHTkSs3OZQN063X9j5w6ehZ5Zn/KQQgABl8oA= Message-ID: References: <20120312165912.1431.16165.idtracker@ietfa.amsl.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E1FBE81@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E1FBE81@inba-mail01.sonusnet.com> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Change Summary & Review request: I-D Action: draft-ietf-siprec-metadata-06.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 17:22:49 -0000 Partha Section 6.7.3 talks about media mode, but I cant find any such attribute in= the xml schema or examples. Rgds John Stafford | Solution Architect 1 | BT Global Services=20 ________________________________________ From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of Ravind= ran, Parthasarathi [pravindran@sonusnet.com] Sent: 13 March 2012 10:12 To: siprec@ietf.org Subject: [siprec] Change Summary & Review request: I-D Action: draft-ietf-s= iprec-metadata-06.txt Hi all, IETF-82 SIPREC meeting consensus and other SIPREC mailing consensus after -= 05 revision of metadata draft are updated in this revision. Summary of chan= ges between -05 and -06 are as follows: 1) The association between participant and CS is changed as 0..* from 2..* 2) Associate-time and disassociate-time attributes in CS are moved to Parti= cipantCSAssociation 3) CSRSassociation metadata element creation to indicate the attributes rel= ated to CS and RS. 4) participantsessionassoc XML element is added to represent participant an= d session associated XML elements. 5) CSRC attribute is removed from participantstreamassociation object 6) ParticipantStreamAssoc XML element is introduced for association between= participant and stream XML element. 7) Sec 7 and Appendix B Example update based on new updated metadata XML Sc= hema 7) Proprietary unique-id usage is shown in Sec 7.1 example 8) XML schema update in Sec 8 based on metadata element changes Editorial changes 1) Added reference for reason header, p-asserted-identity 2) Changed RFC reference of RFCxxxx[RFCxxxx] to RFCxxxx 3) Changed *MUST* to MUST in Sec 6.5.3 Could you please review the updated metadata draft at http://www.ietf.org/i= nternet-drafts/draft-ietf-siprec-metadata-06.txt and provide your valuable = comments. Thanks Partha >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of internet-drafts@ietf.org >Sent: Monday, March 12, 2012 10:29 PM >To: i-d-announce@ietf.org >Cc: siprec@ietf.org >Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-06.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. This draft is a work item of the SIP Recording Working >Group of the IETF. > > Title : Session Initiation Protocol (SIP) Recording >Metadata > Author(s) : Ram Mohan Ravindranath > Parthasarathi Ravindran > Paul Kyzivat > Filename : draft-ietf-siprec-metadata-06.txt > Pages : 48 > Date : 2012-03-12 > > Session recording is a critical requirement in many communications > environments such as call centers and financial trading. In some of > these environments, all calls must be recorded for regulatory, > compliance, and consumer protection reasons. Recording of a session > is typically performed by sending a copy of a media stream to a > recording device. This document describes the metadata model as > viewed by Session Recording Server(SRS) and the Recording metadata > format. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-siprec-metadata-06.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >This Internet-Draft can be retrieved at: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-metadata-06.txt > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec= From pravindran@sonusnet.com Tue Mar 13 10:45:16 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331AC21E8056 for ; Tue, 13 Mar 2012 10:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.357 X-Spam-Level: X-Spam-Status: No, score=-4.357 tagged_above=-999 required=5 tests=[AWL=2.242, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ds50tsWCO2Y for ; Tue, 13 Mar 2012 10:45:14 -0700 (PDT) Received: from na3sys010aog106.obsmtp.com (na3sys010aog106.obsmtp.com [74.125.245.80]) by ietfa.amsl.com (Postfix) with ESMTP id D753B21E8049 for ; Tue, 13 Mar 2012 10:45:13 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob106.postini.com ([74.125.244.12]) with SMTP ID DSNKT1+HqSajb152/cACLcqSD4Tfxn+OutaK@postini.com; Tue, 13 Mar 2012 10:45:13 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 13 Mar 2012 13:45:22 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Tue, 13 Mar 2012 23:15:03 +0530 From: "Ravindran, Parthasarathi" To: "john.2.stafford@bt.com" , "siprec@ietf.org" Thread-Topic: [siprec] Change Summary & Review request: I-D Action: draft-ietf-siprec-metadata-06.txt Thread-Index: AQHNAT3rBkvmlth+sES1X2m99MMpXJZoeonA Date: Tue, 13 Mar 2012 17:45:02 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E1FC3BD@inba-mail01.sonusnet.com> References: <20120312165912.1431.16165.idtracker@ietfa.amsl.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E1FBE81@inba-mail01.sonusnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Change Summary & Review request: I-D Action: draft-ietf-siprec-metadata-06.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 17:45:16 -0000 Hi John, Thanks for pointing to the text which was not removed as part of media mode= attribute removal from the draft. I'll remove it in the next revision. I'll give some background why this attribute was removed in the draft as it= may be of your interest. Initially open question was how to represent the = mixed stream in the metadata. The simplest solution is to indicate whether = the stream is mixed or not-mixed as part of Stream XML itself and the attri= bute was added. While we discussing the relationship between participant an= d stream using "send" & "recv" attribute, it was clear that there is no nee= d of explicitly mention using attribute like media mode but "send" by multi= ple participant for the specific stream will represent mixed stream. Of cou= rse, the obvious next question is how to know whether the specific particip= ant is sending the stream at the given time or not. It is not possible usin= g simple SDP or metadata XML wherein CSRC information may be used. As discu= ssed in IETF-82, CSRC attribute has lot of controversy. So, RTCP/RTP (CSRC/= SSRC) information is the only available information to know about the contr= ibuting source for the recorded mixed stream. Thanks Partha >-----Original Message----- >From: john.2.stafford@bt.com [mailto:john.2.stafford@bt.com] >Sent: Tuesday, March 13, 2012 10:53 PM >To: Ravindran, Parthasarathi; siprec@ietf.org >Subject: RE: [siprec] Change Summary & Review request: I-D Action: >draft-ietf-siprec-metadata-06.txt > >Partha > >Section 6.7.3 talks about media mode, but I cant find any such attribute >in the xml schema or examples. > > > >Rgds >John Stafford | Solution Architect 1 | BT Global Services >________________________________________ >From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of >Ravindran, Parthasarathi [pravindran@sonusnet.com] >Sent: 13 March 2012 10:12 >To: siprec@ietf.org >Subject: [siprec] Change Summary & Review request: I-D Action: draft- >ietf-siprec-metadata-06.txt > >Hi all, > >IETF-82 SIPREC meeting consensus and other SIPREC mailing consensus >after -05 revision of metadata draft are updated in this revision. >Summary of changes between -05 and -06 are as follows: > >1) The association between participant and CS is changed as 0..* from >2..* >2) Associate-time and disassociate-time attributes in CS are moved to >ParticipantCSAssociation >3) CSRSassociation metadata element creation to indicate the attributes >related to CS and RS. >4) participantsessionassoc XML element is added to represent participant >and session associated XML elements. >5) CSRC attribute is removed from participantstreamassociation object >6) ParticipantStreamAssoc XML element is introduced for association >between participant and stream XML element. >7) Sec 7 and Appendix B Example update based on new updated metadata XML >Schema >7) Proprietary unique-id usage is shown in Sec 7.1 example >8) XML schema update in Sec 8 based on metadata element changes > >Editorial changes >1) Added reference for reason header, p-asserted-identity >2) Changed RFC reference of RFCxxxx[RFCxxxx] to RFCxxxx >3) Changed *MUST* to MUST in Sec 6.5.3 > >Could you please review the updated metadata draft at >http://www.ietf.org/internet-drafts/draft-ietf-siprec-metadata-06.txt >and provide your valuable comments. > >Thanks >Partha > >>-----Original Message----- >>From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>Behalf Of internet-drafts@ietf.org >>Sent: Monday, March 12, 2012 10:29 PM >>To: i-d-announce@ietf.org >>Cc: siprec@ietf.org >>Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-06.txt >> >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. This draft is a work item of the SIP Recording Working >>Group of the IETF. >> >> Title : Session Initiation Protocol (SIP) Recording >>Metadata >> Author(s) : Ram Mohan Ravindranath >> Parthasarathi Ravindran >> Paul Kyzivat >> Filename : draft-ietf-siprec-metadata-06.txt >> Pages : 48 >> Date : 2012-03-12 >> >> Session recording is a critical requirement in many communications >> environments such as call centers and financial trading. In some of >> these environments, all calls must be recorded for regulatory, >> compliance, and consumer protection reasons. Recording of a session >> is typically performed by sending a copy of a media stream to a >> recording device. This document describes the metadata model as >> viewed by Session Recording Server(SRS) and the Recording metadata >> format. >> >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-siprec-metadata-06.txt >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>This Internet-Draft can be retrieved at: >>ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-metadata-06.txt >> >>_______________________________________________ >>siprec mailing list >>siprec@ietf.org >>https://www.ietf.org/mailman/listinfo/siprec >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From pravindran@sonusnet.com Wed Mar 14 07:05:35 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DDA21F87E1 for ; Wed, 14 Mar 2012 07:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzylVxdyHWlZ for ; Wed, 14 Mar 2012 07:05:33 -0700 (PDT) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with ESMTP id A230D21F87D6 for ; Wed, 14 Mar 2012 07:05:32 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKT2ClrF/9H7iCf2Huuy76BChfGNeLGzSy@postini.com; Wed, 14 Mar 2012 07:05:32 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 14 Mar 2012 10:05:39 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Wed, 14 Mar 2012 19:35:25 +0530 From: "Ravindran, Parthasarathi" To: Bruce Chrustie , "siprec@ietf.org" Thread-Topic: Use Case 10 & 12 Thread-Index: Acz8qEKzd+3W9yEPSQu279GFn3tLGgASkumAABMYvFABKvEdsA== Date: Wed, 14 Mar 2012 14:05:25 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E1FCAAE@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E1F4EB4@inba-mail01.sonusnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.67] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C0E1FCAAEinbamail01sonus_" MIME-Version: 1.0 Subject: Re: [siprec] Use Case 10 & 12 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 14:05:35 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C0E1FCAAEinbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bruce, SIPREC model is much more complicated in terms of relationship between RS a= nd CS. The possible combination of RS & CS relationship are 1 RS : 1 CS 1 RS : N CS N RS : 1 CS So, each of the model may prefer the different action and it is upto the sp= ecific deployment. N RS: 1 CS deployment will continue CS irrespective of t= he RS termination. Also in case the intention is to terminate CS using RS SIP mechanism, it is= certainly outside the scope of SIPREC as it falls under SIP "action" or ca= ll control functionality. Thanks Partha From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Bruce Chrustie Sent: Thursday, March 08, 2012 8:56 PM To: siprec@ietf.org Subject: Re: [siprec] Use Case 10 & 12 Hi Partha, We agree on the action the SRC should take. My issue is that there is nothi= ng in draft-ietf-siprec-protocol-02 that calls this behavior out explicitly= in section 5 & 6 and it needs to be there. Further, there are two scenarios: 'financial bank' and 'webstore callcenter= ' 'financial bank' is mandated to record all calls, and if the RS drops the c= orresponding CS should be dropped 'webstore callcenter' records for informational purposes a fraction of thei= r calls. Having a RS fail would not dictate a CS termination. This variability in what happens in the SRC right now is ambiguous and I th= ink it needs to be addressed explicitly both in addition to callflows betwe= en the SRS to SRC when it wants a CS terminated as well as SRC behavior upo= n a RS termination during an active CS. Bruce From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] Sent: Thursday, March 08, 2012 1:25 AM To: Bruce Chrustie; siprec@ietf.org Subject: RE: Use Case 10 & 12 Bruce, CS termination in SRC based on RS termination from SRS is a policy decision= in SRC and It is clear in usecase 10(High availability) as follows: o The Communication Session must be terminated (or suitable notification given to parties) in the event of a recording failure. In case of recording failure, SRC may indicate the notification to the part= ies using "record" attribute in draft-ietf-siprec-protocol or send BYE towa= rds both parties. For usecase #12, Real-time analytics may be employed for automatic intervention (stopping interaction or alerting) if for example, a trader is not following regulations. In case of real-time analytics, SRC application has to be terminate CS or a= lert the user about failure to record in case of RS is terminated. Thanks Partha From: siprec-bounces@ietf.org [mailto:sipre= c-bounces@ietf.org] On Behalf Of B= ruce Chrustie Sent: Thursday, March 08, 2012 3:14 AM To: siprec@ietf.org Subject: [siprec] Use Case 10 & 12 Hi gang, Looking at these use cases in the RFC I see the need for the SRC to termina= te a CS based upon an autonomous activities within the SRS. I see a couple = options on how this would happen: -SRS terminates the RS and the SRC has an implementation to terminate the C= S in such instances. The struggle I have with this is that it is vendor dep= endent on if/how it is implemented. Especially relevant to #12. There is no= thing I see within the drafts that would force a SRC to drop a CS because a= RS was dropped. It would not make sense to do so either without it being e= xplicitly requested. -SRS sends BYE with metadata to terminate the CS by the SRC. Not able to to= day. Can you enlighten me with some signaling scenarios on what the initial solu= tions were to these two scenarios? My preference is there is explicit capab= ility within protocol & metadata that a CS be terminated when a SRS sends a= BYE (or some variation). Bruce, --_000_387F9047F55E8C42850AD6B3A7A03C6C0E1FCAAEinbamail01sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bruce,

 

SIPREC model is much m= ore complicated in terms of relationship between RS and CS. The possible co= mbination of RS & CS relationship are

 

1 RS :  1 CS=

1 RS :  N CS=

N RS :  1 CS=

 

So, each of the model = may prefer the different action and it is upto the specific deployment. N R= S: 1 CS deployment will continue CS irrespective of the RS termination.

 

Also in case the inten= tion is to terminate CS using RS SIP mechanism, it is certainly outside the= scope of SIPREC as it falls under SIP “action” or call control= functionality.

 

Thanks

Partha

 

From: siprec-b= ounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Bruce Chrustie
Sent: Thursday, March 08, 2012 8:56 PM
To: siprec@ietf.org
Subject: Re: [siprec] Use Case 10 & 12

 

Hi Partha,<= /span>

 

We agree on the action= the SRC should take. My issue is that there is nothing in draft-ietf-sipre= c-protocol-02 that calls this behavior out explicitly in section 5 & 6 = and it needs to be there.

 

Further, there are two= scenarios: ‘financial bank’ and ‘webstore callcenterR= 17;

 

‘financial bank&= #8217; is mandated to record all calls, and if the RS drops the correspondi= ng CS should be dropped

 

‘webstore callce= nter’ records for informational purposes a fraction of their calls. H= aving a RS fail would not dictate a CS termination.

 

This variability in wh= at happens in the SRC right now is ambiguous and I think it needs to be add= ressed explicitly both in addition to callflows between the SRS to SRC when= it wants a CS terminated as well as SRC behavior upon a RS termination during an active CS.<= /p>

 

Bruce

 

 

 

From: Ravindra= n, Parthasarathi [mailto:pravind= ran@sonusnet.com]
Sent: Thursday, March 08, 2012 1:25 AM
To: Bruce Chrustie; siprec@ietf.o= rg
Subject: RE: Use Case 10 & 12

 

Bruce,

 

CS termination in SRC = based on RS termination from SRS is a policy decision in SRC and  It i= s clear in usecase 10(High availability) as follows:

 

  = ;    o  The Communication Session must be terminated (o= r suitable

  = ;       notification given to parties) in the= event of a recording

  = ;       failure.

 =

In case of recording f= ailure, SRC may indicate the notification to the parties using “recor= d” attribute in draft-ietf-siprec-protocol or send BYE towards both p= arties.

 

For usecase #12,<= /o:p>

 

Real-time analytics may be employed for automatic intervention (s=
topping
   interaction or alerting) if for example, a trader is=
 not following
   regulations.
 

In case of real-time a= nalytics, SRC application has to be terminate CS or alert the user about fa= ilure to record in case of RS is terminated.

 

Thanks

Partha

 

From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Bruce Chrustie
Sent: Thursday, March 08, 2012 3:14 AM
To: siprec@ietf.org
Subject: [siprec] Use Case 10 & 12

 

Hi gang,

 

Looking at these use cases in the RFC I see the need= for the SRC to terminate a CS based upon an autonomous activities within t= he SRS. I see a couple options on how this would happen:

 

-SRS terminates the RS and the SRC has an implementa= tion to terminate the CS in such instances. The struggle I have with this i= s that it is vendor dependent on if/how it is implemented. Especially relev= ant to #12. There is nothing I see within the drafts that would force a SRC to drop a CS because a RS was dro= pped. It would not make sense to do so either without it being explicitly r= equested.

 

-SRS sends BYE with metadata to terminate the CS by = the SRC. Not able to today.

 

Can you enlighten me with some signaling scenarios o= n what the initial solutions were to these two scenarios? My preference is = there is explicit capability within protocol & metadata that a CS be te= rminated when a SRS sends a BYE (or some variation).

 

Bruce,

--_000_387F9047F55E8C42850AD6B3A7A03C6C0E1FCAAEinbamail01sonus_-- From pravindran@sonusnet.com Wed Mar 14 07:12:38 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F0C21F8828 for ; Wed, 14 Mar 2012 07:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZmWVxHnmESG for ; Wed, 14 Mar 2012 07:12:37 -0700 (PDT) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by ietfa.amsl.com (Postfix) with ESMTP id F3C3821F8827 for ; Wed, 14 Mar 2012 07:12:36 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKT2CnVCwLS25DE8QdoFt2uJzbuuetJ+Up@postini.com; Wed, 14 Mar 2012 07:12:37 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 14 Mar 2012 10:12:46 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Wed, 14 Mar 2012 19:42:30 +0530 From: "Ravindran, Parthasarathi" To: Leon Portman , "siprec@ietf.org" Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt Thread-Index: AQHNAFN+7jAuVLtiI0aefxoa4INav5ZoBQaAgAHS3hA= Date: Wed, 14 Mar 2012 14:12:29 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E1FCACA@inba-mail01.sonusnet.com> References: <20120312132433.19581.40959.idtracker@ietfa.amsl.com> <07465C1D981ABC41A344374066AE1A2C39DAF8C0A7@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C39DAF8C0A7@TLVMBX01.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 14:12:38 -0000 Leon, Could you please explain in detail about Sec 3.2.2 update " o The actual mechanism of the identification is depends on SRC policy." Thanks partha >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Leon Portman >Sent: Tuesday, March 13, 2012 9:20 PM >To: siprec@ietf.org >Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt > >Main changes. They are mainly consist from Gonzalo and other mailing >lists comments. > >1. Definitions: Adding recording unaware UA definition and fixing some >other definitions 2. Consistent abbreviation usage in the document 3. >Figures fixes 4. Adding policy mentions in Endpoint as SRC 5. Removing >WEBRTC mentions 6. Adding more descriptions in SRS initiated flows >7.Adding support for RS without metadata > >There are some small typo mistakes in v04. I have already fixed them and >will update in next version > >Regards > >Leon > >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of internet-drafts@ietf.org >Sent: Monday, March 12, 2012 3:25 PM >To: i-d-announce@ietf.org >Cc: siprec@ietf.org >Subject: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. This draft is a work item of the SIP Recording Working >Group of the IETF. > > Title : An Architecture for Media Recording using the >Session Initiation Protocol > Author(s) : Andrew Hutton > Leon Portman > Rajnish Jain > Ken Rehor > Filename : draft-ietf-siprec-architecture-04.txt > Pages : 16 > Date : 2012-03-12 > > Session recording is a critical requirement in many communications > environments such as call centers and financial trading. In some of > these environments, all calls must be recorded for regulatory, > compliance, and consumer protection reasons. Recording of a session > is typically performed by sending a copy of a media stream to a > recording device. This document describes architectures for > deploying session recording solutions in an environment which is > based on the Session Initiation Protocol (SIP). > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-siprec-architecture- >04.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >This Internet-Draft can be retrieved at: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-architecture-04.txt > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From pravindran@sonusnet.com Wed Mar 14 10:19:22 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E592121F871B for ; Wed, 14 Mar 2012 10:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.412 X-Spam-Level: X-Spam-Status: No, score=-4.412 tagged_above=-999 required=5 tests=[AWL=2.187, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kV1CNtHNzFzH for ; Wed, 14 Mar 2012 10:19:22 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with ESMTP id E757721F8722 for ; Wed, 14 Mar 2012 10:19:21 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKT2DTGaJ/vTIsZ14IRPB58ySiBXL4T1l1@postini.com; Wed, 14 Mar 2012 10:19:22 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 14 Mar 2012 13:19:30 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Wed, 14 Mar 2012 22:49:15 +0530 From: "Ravindran, Parthasarathi" To: Leon Portman , "siprec@ietf.org" Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt Thread-Index: AQHNAFN+7jAuVLtiI0aefxoa4INav5ZoBQaAgAHS3hCAADP94A== Date: Wed, 14 Mar 2012 17:19:26 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E1FCC2C@inba-mail01.sonusnet.com> References: <20120312132433.19581.40959.idtracker@ietfa.amsl.com> <07465C1D981ABC41A344374066AE1A2C39DAF8C0A7@TLVMBX01.nice.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FCACA@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E1FCACA@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 17:19:23 -0000 Leon, Adding to the previous query, the same section mentions about join header u= sage " o Identify the session that is to be recorded - Possibly using the Join header [RFC3911]" The problem with Join header is that Join header maps dialog and not CS. So= , it is not generic approach for SIPREC. Please clarify in case I'm missing= something here. Thanks Partha >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Ravindran, Parthasarathi >Sent: Wednesday, March 14, 2012 7:42 PM >To: Leon Portman; siprec@ietf.org >Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt > >Leon, > >Could you please explain in detail about Sec 3.2.2 update > >" o The actual mechanism of the identification is depends on SRC > policy." > >Thanks >partha > >>-----Original Message----- >>From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>Behalf Of Leon Portman >>Sent: Tuesday, March 13, 2012 9:20 PM >>To: siprec@ietf.org >>Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt >> >>Main changes. They are mainly consist from Gonzalo and other mailing >>lists comments. >> >>1. Definitions: Adding recording unaware UA definition and fixing some >>other definitions 2. Consistent abbreviation usage in the document 3. >>Figures fixes 4. Adding policy mentions in Endpoint as SRC 5. Removing >>WEBRTC mentions 6. Adding more descriptions in SRS initiated flows >>7.Adding support for RS without metadata >> >>There are some small typo mistakes in v04. I have already fixed them >>and will update in next version >> >>Regards >> >>Leon >> >>-----Original Message----- >>From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>Behalf Of internet-drafts@ietf.org >>Sent: Monday, March 12, 2012 3:25 PM >>To: i-d-announce@ietf.org >>Cc: siprec@ietf.org >>Subject: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt >> >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. This draft is a work item of the SIP Recording Working >>Group of the IETF. >> >> Title : An Architecture for Media Recording using the >>Session Initiation Protocol >> Author(s) : Andrew Hutton >> Leon Portman >> Rajnish Jain >> Ken Rehor >> Filename : draft-ietf-siprec-architecture-04.txt >> Pages : 16 >> Date : 2012-03-12 >> >> Session recording is a critical requirement in many communications >> environments such as call centers and financial trading. In some of >> these environments, all calls must be recorded for regulatory, >> compliance, and consumer protection reasons. Recording of a session >> is typically performed by sending a copy of a media stream to a >> recording device. This document describes architectures for >> deploying session recording solutions in an environment which is >> based on the Session Initiation Protocol (SIP). >> >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-siprec-architecture- >>04.txt >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>This Internet-Draft can be retrieved at: >>ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-architecture-04.tx >>t >> >>_______________________________________________ >>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 brian.rosen@neustar.biz Fri Mar 16 10:34:13 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4F121F8642 for ; Fri, 16 Mar 2012 10:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.371 X-Spam-Level: X-Spam-Status: No, score=-5.371 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aq4FZlhWzDW for ; Fri, 16 Mar 2012 10:34:12 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id AC61521F85CC for ; Fri, 16 Mar 2012 10:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1331919405; x=1647274299; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=l2LnBvCT6SqV39qsu0Y4z XfQMaxleNdJWIgi2ZoL2J0=; b=SjNCiekZVLQ/gjwKmNbtzffLSCZcUXM/YrZEP 8LNGtZmEW6Q00hyScbUyYve9lf4O/NHdow1sCFvgmVbc4+1JA== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.6795855; Fri, 16 Mar 2012 13:36:44 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Fri, 16 Mar 2012 13:34:08 -0400 From: "Rosen, Brian" To: "siprec@ietf.org" Date: Fri, 16 Mar 2012 13:34:06 -0400 Thread-Topic: WGLC on draft-ietf-siprec-architecture Thread-Index: Ac0Dmv2cHHcO9ke8SRWQREeDPOVpOA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 63J1ISCq97DH8NZ/qREM7A== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] WGLC on draft-ietf-siprec-architecture X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 16 Mar 2012 17:34:13 -0000 We would like to start working group last call on -architecture-04. Normal= ly, we would have a two week WGLC, but since the IETF meeting falls in the = middle, we will extend it to April 6th. Please review the draft, even if you have looked at it before. Please send= comments to the list as soon as possible. Brian From leon.portman@gmail.com Fri Mar 16 10:43:37 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93DA21E804E for ; Fri, 16 Mar 2012 10:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtZ3bHbvY2BQ for ; Fri, 16 Mar 2012 10:43:37 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B77A721E8012 for ; Fri, 16 Mar 2012 10:43:36 -0700 (PDT) Received: by werb10 with SMTP id b10so5107321wer.31 for ; Fri, 16 Mar 2012 10:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=jybXU30CsuBpG7LoJQ6XF5xT5V5lOsNDu29pEzhcqUo=; b=sctQ4WuwJ06WuQuUC9YoV60gncL9YyH/hlD6b510gNxiiRg4OqJ8Hw5L9ZZyqxCzaQ Yu1bNP7zqxo3WmYMCQbcHZGE2LbRNlustxAfMdhnaWbswYEhBOfPLQ+Efl4ERqWB0rnk 5xSGG1KVYpbO8+qfnklPpFdeeCh21nvHyRxXF9HFNzmkfRi1u+8LcLCgYXfnMWy7JHOa aVgn71QJdrBaVh088PaLK4oNOLONK8pFzor6ZYCfBKq67jnEAaPf+2QIdyaSY1X+46ak BlceF9XgbvuXW8R4M8forkr+PzfDWnRwfsRXhGDX82aPzck0kgg+5kdm7kb1k0lWeMWA RP6A== Received: by 10.216.135.199 with SMTP id u49mr2207862wei.7.1331919815801; Fri, 16 Mar 2012 10:43:35 -0700 (PDT) Received: from [192.168.1.108] ([212.150.140.190]) by mx.google.com with ESMTPS id 9sm637172wid.2.2012.03.16.10.43.33 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Mar 2012 10:43:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1426\)) From: Leon Portman In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E1FCACA@inba-mail01.sonusnet.com> Date: Fri, 16 Mar 2012 19:43:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120312132433.19581.40959.idtracker@ietfa.amsl.com> <07465C1D981ABC41A344374066AE1A2C39DAF8C0A7@TLVMBX01.nice.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FCACA@inba-mail01.sonusnet.com> To: "Ravindran, Parthasarathi" X-Mailer: Apple Mail (2.1426) Cc: "siprec@ietf.org" Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 17:43:38 -0000 Partha Hi The ways of identification of CS to be recorded for SRS initiated flows = are very dependent on actual SRC implementation. For example, if SRC is PBX, it can be even CTI call id, participants = ids, DNS name of end point etc. For gateways it can be IP and PORT of RTP stream for example.=20 This what i meant that it is very defendant on SRC and on the way how = SRS knows about CSs. Regards Leon On Mar 14, 2012, at 4:12 PM, "Ravindran, Parthasarathi" = wrote: > Leon, >=20 > Could you please explain in detail about Sec 3.2.2 update >=20 > " o The actual mechanism of the identification is depends on SRC > policy." >=20 > Thanks > partha >=20 >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On = Behalf >> Of Leon Portman >> Sent: Tuesday, March 13, 2012 9:20 PM >> To: siprec@ietf.org >> Subject: Re: [siprec] I-D Action: = draft-ietf-siprec-architecture-04.txt >>=20 >> Main changes. They are mainly consist from Gonzalo and other mailing >> lists comments. >>=20 >> 1. Definitions: Adding recording unaware UA definition and fixing = some >> other definitions 2. Consistent abbreviation usage in the document 3. >> Figures fixes 4. Adding policy mentions in Endpoint as SRC 5. = Removing >> WEBRTC mentions 6. Adding more descriptions in SRS initiated flows >> 7.Adding support for RS without metadata >>=20 >> There are some small typo mistakes in v04. I have already fixed them = and >> will update in next version >>=20 >> Regards >>=20 >> Leon >>=20 >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On = Behalf >> Of internet-drafts@ietf.org >> Sent: Monday, March 12, 2012 3:25 PM >> To: i-d-announce@ietf.org >> Cc: siprec@ietf.org >> Subject: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the SIP Recording Working >> Group of the IETF. >>=20 >> Title : An Architecture for Media Recording using the >> Session Initiation Protocol >> Author(s) : Andrew Hutton >> Leon Portman >> Rajnish Jain >> Ken Rehor >> Filename : draft-ietf-siprec-architecture-04.txt >> Pages : 16 >> Date : 2012-03-12 >>=20 >> Session recording is a critical requirement in many communications >> environments such as call centers and financial trading. In some of >> these environments, all calls must be recorded for regulatory, >> compliance, and consumer protection reasons. Recording of a session >> is typically performed by sending a copy of a media stream to a >> recording device. This document describes architectures for >> deploying session recording solutions in an environment which is >> based on the Session Initiation Protocol (SIP). >>=20 >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-siprec-architecture- >> 04.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-architecture-04.txt >>=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 From pravindran@sonusnet.com Fri Mar 16 10:59:53 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF84D21F8764 for ; Fri, 16 Mar 2012 10:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.561 X-Spam-Level: X-Spam-Status: No, score=-4.561 tagged_above=-999 required=5 tests=[AWL=2.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeigEUIREGbw for ; Fri, 16 Mar 2012 10:59:49 -0700 (PDT) Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with ESMTP id 4556C21F8763 for ; Fri, 16 Mar 2012 10:59:49 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKT2N/lPcPKTr40stgy6tsX9cvmMyBlnTN@postini.com; Fri, 16 Mar 2012 10:59:49 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 16 Mar 2012 13:59:55 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Fri, 16 Mar 2012 23:29:39 +0530 From: "Ravindran, Parthasarathi" To: Leon Portman Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt Thread-Index: AQHNAFN+7jAuVLtiI0aefxoa4INav5ZoBQaAgAHS3hCAAwPfAIAAXQiA Date: Fri, 16 Mar 2012 17:59:38 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAD4@inba-mail01.sonusnet.com> References: <20120312132433.19581.40959.idtracker@ietfa.amsl.com> <07465C1D981ABC41A344374066AE1A2C39DAF8C0A7@TLVMBX01.nice.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FCACA@inba-mail01.sonusnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 17:59:53 -0000 Leon, I agree with you that it is the way proprietary SIP recording works today. = For each SRS initiated callflow, unique-id of a session is generated by PBX= driven or CTI, SRC is forced to develop multiple solutions accordingly as = there is a lack of standard mechanism. I have concern because SRS initiate= d without any specific identification continue the same trend of today's pr= oprietary recording solution. I wish to see some well-defined protocol mech= anism from SRS to SRC to identity the session which has to recorded. Please= let me know your opinion.=20 As you have listed number of mechanism, I'm fine in case we nailed down to = one of the mechanism as standard in the worst case. Thanks Partha=20 >-----Original Message----- >From: Leon Portman [mailto:leon.portman@gmail.com] >Sent: Friday, March 16, 2012 11:14 PM >To: Ravindran, Parthasarathi >Cc: Leon Portman; siprec@ietf.org >Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt > >Partha Hi > >The ways of identification of CS to be recorded for SRS initiated flows >are very dependent on actual SRC implementation. >For example, if SRC is PBX, it can be even CTI call id, participants >ids, DNS name of end point etc. > >For gateways it can be IP and PORT of RTP stream for example. > >This what i meant that it is very defendant on SRC and on the way how >SRS knows about CSs. > >Regards > >Leon > >On Mar 14, 2012, at 4:12 PM, "Ravindran, Parthasarathi" > wrote: > >> Leon, >> >> Could you please explain in detail about Sec 3.2.2 update >> >> " o The actual mechanism of the identification is depends on SRC >> policy." >> >> Thanks >> partha >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Leon Portman >>> Sent: Tuesday, March 13, 2012 9:20 PM >>> To: siprec@ietf.org >>> Subject: Re: [siprec] I-D Action: >>> draft-ietf-siprec-architecture-04.txt >>> >>> Main changes. They are mainly consist from Gonzalo and other mailing >>> lists comments. >>> >>> 1. Definitions: Adding recording unaware UA definition and fixing >>> some other definitions 2. Consistent abbreviation usage in the >document 3. >>> Figures fixes 4. Adding policy mentions in Endpoint as SRC 5. >>> Removing WEBRTC mentions 6. Adding more descriptions in SRS initiated >>> flows 7.Adding support for RS without metadata >>> >>> There are some small typo mistakes in v04. I have already fixed them >>> and will update in next version >>> >>> Regards >>> >>> Leon >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of internet-drafts@ietf.org >>> Sent: Monday, March 12, 2012 3:25 PM >>> To: i-d-announce@ietf.org >>> Cc: siprec@ietf.org >>> Subject: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. This draft is a work item of the SIP Recording Working >>> Group of the IETF. >>> >>> Title : An Architecture for Media Recording using the >>> Session Initiation Protocol >>> Author(s) : Andrew Hutton >>> Leon Portman >>> Rajnish Jain >>> Ken Rehor >>> Filename : draft-ietf-siprec-architecture-04.txt >>> Pages : 16 >>> Date : 2012-03-12 >>> >>> Session recording is a critical requirement in many communications >>> environments such as call centers and financial trading. In some of >>> these environments, all calls must be recorded for regulatory, >>> compliance, and consumer protection reasons. Recording of a session >>> is typically performed by sending a copy of a media stream to a >>> recording device. This document describes architectures for >>> deploying session recording solutions in an environment which is >>> based on the Session Initiation Protocol (SIP). >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-siprec-architecture- >>> 04.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-architecture-04. >>> txt >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec From leon.portman@gmail.com Fri Mar 16 11:06:12 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B3B21E8059 for ; Fri, 16 Mar 2012 11:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-BhEXfbetxg for ; Fri, 16 Mar 2012 11:06:12 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 9239B21E8034 for ; Fri, 16 Mar 2012 11:06:11 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so982318wib.13 for ; Fri, 16 Mar 2012 11:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ZrgLGw8cc5osftGiC+xAmmh5Uct0fSnDD0U7+SlVhM0=; b=yRIRLG9bG/7AfSAd7hSq6cwObAiOW4/lEYQ/RNdAzwITd9K0bJ7WEtTO2YJxG4eEd4 A9x7AxMY6TZNtKhvBJVx+whYbCFCXL2GXFJnoj+tICo7eF+Kfq167MH9N6wSNEaNHy3b 8paCko2evjzPeZYld/6VnahkJOyXG/tspnz7+vHHjdZkunZUce2BxdX38Y8Dm/eRd5Dk +HYFxkEoaTYXCrTLlqC02Q4JEizIgMO+umcVy3mU3ZttbvPbCnUJ7j6MXz3XNRLqk5gx LPHWSUpsoSvdEigPZ2eG8HRyeterFQNSRnkeFtClfGccJqTyKFdbPLMfBt9+RwYOGJHu 5Jpg== Received: by 10.180.19.37 with SMTP id b5mr561302wie.9.1331921170619; Fri, 16 Mar 2012 11:06:10 -0700 (PDT) Received: from [192.168.1.108] ([212.150.140.190]) by mx.google.com with ESMTPS id k7sm832289wia.5.2012.03.16.11.06.08 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Mar 2012 11:06:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1426\)) From: Leon Portman In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAD4@inba-mail01.sonusnet.com> Date: Fri, 16 Mar 2012 20:06:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <02E25602-BB51-4091-95E3-A5475AB4B85D@gmail.com> References: <20120312132433.19581.40959.idtracker@ietfa.amsl.com> <07465C1D981ABC41A344374066AE1A2C39DAF8C0A7@TLVMBX01.nice.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FCACA@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAD4@inba-mail01.sonusnet.com> To: "Ravindran, Parthasarathi" X-Mailer: Apple Mail (2.1426) Cc: "siprec@ietf.org" Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 18:06:12 -0000 Partha, I completely agree with you. Session identification is one of the main = pain points today. May be Global session ID work will help here?=20 http://tools.ietf.org/html/draft-kaplan-dispatch-session-id-01 Leon On Mar 16, 2012, at 7:59 PM, "Ravindran, Parthasarathi" = wrote: > Leon, >=20 > I agree with you that it is the way proprietary SIP recording works = today. For each SRS initiated callflow, unique-id of a session is = generated by PBX driven or CTI, SRC is forced to develop multiple = solutions accordingly as there is a lack of standard mechanism. I have = concern because SRS initiated without any specific identification = continue the same trend of today's proprietary recording solution. I = wish to see some well-defined protocol mechanism from SRS to SRC to = identity the session which has to recorded. Please let me know your = opinion.=20 >=20 > As you have listed number of mechanism, I'm fine in case we nailed = down to one of the mechanism as standard in the worst case. >=20 > Thanks > Partha=20 >=20 >> -----Original Message----- >> From: Leon Portman [mailto:leon.portman@gmail.com] >> Sent: Friday, March 16, 2012 11:14 PM >> To: Ravindran, Parthasarathi >> Cc: Leon Portman; siprec@ietf.org >> Subject: Re: [siprec] I-D Action: = draft-ietf-siprec-architecture-04.txt >>=20 >> Partha Hi >>=20 >> The ways of identification of CS to be recorded for SRS initiated = flows >> are very dependent on actual SRC implementation. >> For example, if SRC is PBX, it can be even CTI call id, participants >> ids, DNS name of end point etc. >>=20 >> For gateways it can be IP and PORT of RTP stream for example. >>=20 >> This what i meant that it is very defendant on SRC and on the way how >> SRS knows about CSs. >>=20 >> Regards >>=20 >> Leon >>=20 >> On Mar 14, 2012, at 4:12 PM, "Ravindran, Parthasarathi" >> wrote: >>=20 >>> Leon, >>>=20 >>> Could you please explain in detail about Sec 3.2.2 update >>>=20 >>> " o The actual mechanism of the identification is depends on SRC >>> policy." >>>=20 >>> Thanks >>> partha >>>=20 >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of Leon Portman >>>> Sent: Tuesday, March 13, 2012 9:20 PM >>>> To: siprec@ietf.org >>>> Subject: Re: [siprec] I-D Action: >>>> draft-ietf-siprec-architecture-04.txt >>>>=20 >>>> Main changes. They are mainly consist from Gonzalo and other = mailing >>>> lists comments. >>>>=20 >>>> 1. Definitions: Adding recording unaware UA definition and fixing >>>> some other definitions 2. Consistent abbreviation usage in the >> document 3. >>>> Figures fixes 4. Adding policy mentions in Endpoint as SRC 5. >>>> Removing WEBRTC mentions 6. Adding more descriptions in SRS = initiated >>>> flows 7.Adding support for RS without metadata >>>>=20 >>>> There are some small typo mistakes in v04. I have already fixed = them >>>> and will update in next version >>>>=20 >>>> Regards >>>>=20 >>>> Leon >>>>=20 >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of internet-drafts@ietf.org >>>> Sent: Monday, March 12, 2012 3:25 PM >>>> To: i-d-announce@ietf.org >>>> Cc: siprec@ietf.org >>>> Subject: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. This draft is a work item of the SIP Recording Working >>>> Group of the IETF. >>>>=20 >>>> Title : An Architecture for Media Recording using the >>>> Session Initiation Protocol >>>> Author(s) : Andrew Hutton >>>> Leon Portman >>>> Rajnish Jain >>>> Ken Rehor >>>> Filename : draft-ietf-siprec-architecture-04.txt >>>> Pages : 16 >>>> Date : 2012-03-12 >>>>=20 >>>> Session recording is a critical requirement in many communications >>>> environments such as call centers and financial trading. In some = of >>>> these environments, all calls must be recorded for regulatory, >>>> compliance, and consumer protection reasons. Recording of a = session >>>> is typically performed by sending a copy of a media stream to a >>>> recording device. This document describes architectures for >>>> deploying session recording solutions in an environment which is >>>> based on the Session Initiation Protocol (SIP). >>>>=20 >>>>=20 >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-siprec-architecture- >>>> 04.txt >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> This Internet-Draft can be retrieved at: >>>> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-architecture-04. >>>> txt >>>>=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 From pravindran@sonusnet.com Fri Mar 16 11:16:10 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77BBC21E8059 for ; Fri, 16 Mar 2012 11:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.606 X-Spam-Level: X-Spam-Status: No, score=-4.606 tagged_above=-999 required=5 tests=[AWL=1.993, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2VYvas5vkcX for ; Fri, 16 Mar 2012 11:16:09 -0700 (PDT) Received: from na3sys010aog111.obsmtp.com (na3sys010aog111.obsmtp.com [74.125.245.90]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA7B21F85D2 for ; Fri, 16 Mar 2012 11:16:09 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob111.postini.com ([74.125.244.12]) with SMTP ID DSNKT2ODaH9DOMJZk1tpu0acRK+QtcDhXord@postini.com; Fri, 16 Mar 2012 11:16:09 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 16 Mar 2012 14:16:19 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Fri, 16 Mar 2012 23:46:03 +0530 From: "Ravindran, Parthasarathi" To: Leon Portman Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt Thread-Index: AQHNAFN+7jAuVLtiI0aefxoa4INav5ZoBQaAgAHS3hCAAwPfAIAAXQiA//+pRgCAAFzf8A== Date: Fri, 16 Mar 2012 18:16:03 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAF3@inba-mail01.sonusnet.com> References: <20120312132433.19581.40959.idtracker@ietfa.amsl.com> <07465C1D981ABC41A344374066AE1A2C39DAF8C0A7@TLVMBX01.nice.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FCACA@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAD4@inba-mail01.sonusnet.com> <02E25602-BB51-4091-95E3-A5475AB4B85D@gmail.com> In-Reply-To: <02E25602-BB51-4091-95E3-A5475AB4B85D@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 18:16:10 -0000 Leon, I agree with you that session-id solves the reported problem. As you might know, Session id IETF WG namely INSIPID is in the very early s= tage and number of drafts under discussion for IETF-83 are listed in http:/= /www.ietf.org/mail-archive/web/insipid/current/msg00005.html. IMO, creating= session-id dependency will delay SIPREC deliverable. We will brainstorm mo= re to find some way without session-id if exists. Thanks Partha >-----Original Message----- >From: Leon Portman [mailto:leon.portman@gmail.com] >Sent: Friday, March 16, 2012 11:36 PM >To: Ravindran, Parthasarathi >Cc: Leon Portman; siprec@ietf.org >Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt > >Partha, > >I completely agree with you. Session identification is one of the main >pain points today. May be Global session ID work will help here? >http://tools.ietf.org/html/draft-kaplan-dispatch-session-id-01 > >Leon > >On Mar 16, 2012, at 7:59 PM, "Ravindran, Parthasarathi" > wrote: > >> Leon, >> >> I agree with you that it is the way proprietary SIP recording works >today. For each SRS initiated callflow, unique-id of a session is >generated by PBX driven or CTI, SRC is forced to develop multiple >solutions accordingly as there is a lack of standard mechanism. I have >concern because SRS initiated without any specific identification >continue the same trend of today's proprietary recording solution. I >wish to see some well-defined protocol mechanism from SRS to SRC to >identity the session which has to recorded. Please let me know your >opinion. >> >> As you have listed number of mechanism, I'm fine in case we nailed >down to one of the mechanism as standard in the worst case. >> >> Thanks >> Partha >> >>> -----Original Message----- >>> From: Leon Portman [mailto:leon.portman@gmail.com] >>> Sent: Friday, March 16, 2012 11:14 PM >>> To: Ravindran, Parthasarathi >>> Cc: Leon Portman; siprec@ietf.org >>> Subject: Re: [siprec] I-D Action: >>> draft-ietf-siprec-architecture-04.txt >>> >>> Partha Hi >>> >>> The ways of identification of CS to be recorded for SRS initiated >>> flows are very dependent on actual SRC implementation. >>> For example, if SRC is PBX, it can be even CTI call id, participants >>> ids, DNS name of end point etc. >>> >>> For gateways it can be IP and PORT of RTP stream for example. >>> >>> This what i meant that it is very defendant on SRC and on the way how >>> SRS knows about CSs. >>> >>> Regards >>> >>> Leon >>> >>> On Mar 14, 2012, at 4:12 PM, "Ravindran, Parthasarathi" >>> wrote: >>> >>>> Leon, >>>> >>>> Could you please explain in detail about Sec 3.2.2 update >>>> >>>> " o The actual mechanism of the identification is depends on SRC >>>> policy." >>>> >>>> Thanks >>>> partha >>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>> Behalf Of Leon Portman >>>>> Sent: Tuesday, March 13, 2012 9:20 PM >>>>> To: siprec@ietf.org >>>>> Subject: Re: [siprec] I-D Action: >>>>> draft-ietf-siprec-architecture-04.txt >>>>> >>>>> Main changes. They are mainly consist from Gonzalo and other >>>>> mailing lists comments. >>>>> >>>>> 1. Definitions: Adding recording unaware UA definition and fixing >>>>> some other definitions 2. Consistent abbreviation usage in the >>> document 3. >>>>> Figures fixes 4. Adding policy mentions in Endpoint as SRC 5. >>>>> Removing WEBRTC mentions 6. Adding more descriptions in SRS >>>>> initiated flows 7.Adding support for RS without metadata >>>>> >>>>> There are some small typo mistakes in v04. I have already fixed >>>>> them and will update in next version >>>>> >>>>> Regards >>>>> >>>>> Leon >>>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>> Behalf Of internet-drafts@ietf.org >>>>> Sent: Monday, March 12, 2012 3:25 PM >>>>> To: i-d-announce@ietf.org >>>>> Cc: siprec@ietf.org >>>>> Subject: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. This draft is a work item of the SIP Recording Working >>>>> Group of the IETF. >>>>> >>>>> Title : An Architecture for Media Recording using the >>>>> Session Initiation Protocol >>>>> Author(s) : Andrew Hutton >>>>> Leon Portman >>>>> Rajnish Jain >>>>> Ken Rehor >>>>> Filename : draft-ietf-siprec-architecture-04.txt >>>>> Pages : 16 >>>>> Date : 2012-03-12 >>>>> >>>>> Session recording is a critical requirement in many communications >>>>> environments such as call centers and financial trading. In some >>>>> of these environments, all calls must be recorded for regulatory, >>>>> compliance, and consumer protection reasons. Recording of a >>>>> session is typically performed by sending a copy of a media stream >>>>> to a recording device. This document describes architectures for >>>>> deploying session recording solutions in an environment which is >>>>> based on the Session Initiation Protocol (SIP). >>>>> >>>>> >>>>> A URL for this Internet-Draft is: >>>>> http://www.ietf.org/internet-drafts/draft-ietf-siprec-architecture- >>>>> 04.txt >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> This Internet-Draft can be retrieved at: >>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-architecture- >04. >>>>> txt >>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >> From leon.portman@gmail.com Fri Mar 16 11:20:56 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A6D21E8059 for ; Fri, 16 Mar 2012 11:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPXb4OxdUqPp for ; Fri, 16 Mar 2012 11:20:55 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 150F921F862B for ; Fri, 16 Mar 2012 11:20:51 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so999952wib.13 for ; Fri, 16 Mar 2012 11:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=xZuLs06vwyLDKRB4GdiFHM5EgWPcI7IvKXKjIgdwBYM=; b=dPhaX+Z//rgnyKYZLjZAq2TUpskrq6c5xk98uEQ4jPF65RsaZtSRaDP07Hgtl0WSfY myTEWE1JnnZC/afw5/beZDVCgKmUPu0bzifbwN66AHmvDwh5CX2ZOjOPkMpFCafa6k/O A80uEKTtiN7koiBrCX6vOXSpuYhMjQPYBM+ZKb8hjr+8nLBx4WkNaqBR2TMkBQC2zUsP t5xbLYozGdUUNS25YsIrdXteZOKMNQBt4/0kP7FeRWVL+dLt9Y9CPcPbtpcI39jUgyaW DWB/iH8+yauiJ2Ab5amwmADMsCXJQAgsLCrPJHg5dndz5hbO6ltlbmS9EqvzguDu2Dyt UXig== Received: by 10.180.103.35 with SMTP id ft3mr715811wib.0.1331922051210; Fri, 16 Mar 2012 11:20:51 -0700 (PDT) Received: from [192.168.1.108] ([212.150.140.190]) by mx.google.com with ESMTPS id df3sm676909wib.1.2012.03.16.11.20.48 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Mar 2012 11:20:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1426\)) From: Leon Portman In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAF3@inba-mail01.sonusnet.com> Date: Fri, 16 Mar 2012 20:20:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <96F77B6A-C42F-4C45-BF24-F6BF9CCAE026@gmail.com> References: <20120312132433.19581.40959.idtracker@ietfa.amsl.com> <07465C1D981ABC41A344374066AE1A2C39DAF8C0A7@TLVMBX01.nice.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FCACA@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAD4@inba-mail01.sonusnet.com> <02E25602-BB51-4091-95E3-A5475AB4B85D@gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAF3@inba-mail01.sonusnet.com> To: "Ravindran, Parthasarathi" X-Mailer: Apple Mail (2.1426) Cc: "siprec@ietf.org" Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 18:20:56 -0000 The main question then, if it will be required to be defined in the = protocol draft and we can keep architecture draft at high level in order = to move forward Leon On Mar 16, 2012, at 8:16 PM, "Ravindran, Parthasarathi" = wrote: > Leon, >=20 > I agree with you that session-id solves the reported problem. >=20 > As you might know, Session id IETF WG namely INSIPID is in the very = early stage and number of drafts under discussion for IETF-83 are listed = in http://www.ietf.org/mail-archive/web/insipid/current/msg00005.html. = IMO, creating session-id dependency will delay SIPREC deliverable. We = will brainstorm more to find some way without session-id if exists. >=20 > Thanks > Partha >=20 >> -----Original Message----- >> From: Leon Portman [mailto:leon.portman@gmail.com] >> Sent: Friday, March 16, 2012 11:36 PM >> To: Ravindran, Parthasarathi >> Cc: Leon Portman; siprec@ietf.org >> Subject: Re: [siprec] I-D Action: = draft-ietf-siprec-architecture-04.txt >>=20 >> Partha, >>=20 >> I completely agree with you. Session identification is one of the = main >> pain points today. May be Global session ID work will help here? >> http://tools.ietf.org/html/draft-kaplan-dispatch-session-id-01 >>=20 >> Leon >>=20 >> On Mar 16, 2012, at 7:59 PM, "Ravindran, Parthasarathi" >> wrote: >>=20 >>> Leon, >>>=20 >>> I agree with you that it is the way proprietary SIP recording works >> today. For each SRS initiated callflow, unique-id of a session is >> generated by PBX driven or CTI, SRC is forced to develop multiple >> solutions accordingly as there is a lack of standard mechanism. I = have >> concern because SRS initiated without any specific identification >> continue the same trend of today's proprietary recording solution. I >> wish to see some well-defined protocol mechanism from SRS to SRC to >> identity the session which has to recorded. Please let me know your >> opinion. >>>=20 >>> As you have listed number of mechanism, I'm fine in case we nailed >> down to one of the mechanism as standard in the worst case. >>>=20 >>> Thanks >>> Partha >>>=20 >>>> -----Original Message----- >>>> From: Leon Portman [mailto:leon.portman@gmail.com] >>>> Sent: Friday, March 16, 2012 11:14 PM >>>> To: Ravindran, Parthasarathi >>>> Cc: Leon Portman; siprec@ietf.org >>>> Subject: Re: [siprec] I-D Action: >>>> draft-ietf-siprec-architecture-04.txt >>>>=20 >>>> Partha Hi >>>>=20 >>>> The ways of identification of CS to be recorded for SRS initiated >>>> flows are very dependent on actual SRC implementation. >>>> For example, if SRC is PBX, it can be even CTI call id, = participants >>>> ids, DNS name of end point etc. >>>>=20 >>>> For gateways it can be IP and PORT of RTP stream for example. >>>>=20 >>>> This what i meant that it is very defendant on SRC and on the way = how >>>> SRS knows about CSs. >>>>=20 >>>> Regards >>>>=20 >>>> Leon >>>>=20 >>>> On Mar 14, 2012, at 4:12 PM, "Ravindran, Parthasarathi" >>>> wrote: >>>>=20 >>>>> Leon, >>>>>=20 >>>>> Could you please explain in detail about Sec 3.2.2 update >>>>>=20 >>>>> " o The actual mechanism of the identification is depends on = SRC >>>>> policy." >>>>>=20 >>>>> Thanks >>>>> partha >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>>> Behalf Of Leon Portman >>>>>> Sent: Tuesday, March 13, 2012 9:20 PM >>>>>> To: siprec@ietf.org >>>>>> Subject: Re: [siprec] I-D Action: >>>>>> draft-ietf-siprec-architecture-04.txt >>>>>>=20 >>>>>> Main changes. They are mainly consist from Gonzalo and other >>>>>> mailing lists comments. >>>>>>=20 >>>>>> 1. Definitions: Adding recording unaware UA definition and fixing >>>>>> some other definitions 2. Consistent abbreviation usage in the >>>> document 3. >>>>>> Figures fixes 4. Adding policy mentions in Endpoint as SRC 5. >>>>>> Removing WEBRTC mentions 6. Adding more descriptions in SRS >>>>>> initiated flows 7.Adding support for RS without metadata >>>>>>=20 >>>>>> There are some small typo mistakes in v04. I have already fixed >>>>>> them and will update in next version >>>>>>=20 >>>>>> Regards >>>>>>=20 >>>>>> Leon >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>>> Behalf Of internet-drafts@ietf.org >>>>>> Sent: Monday, March 12, 2012 3:25 PM >>>>>> To: i-d-announce@ietf.org >>>>>> Cc: siprec@ietf.org >>>>>> Subject: [siprec] I-D Action: = draft-ietf-siprec-architecture-04.txt >>>>>>=20 >>>>>>=20 >>>>>> A New Internet-Draft is available from the on-line = Internet-Drafts >>>>>> directories. This draft is a work item of the SIP Recording = Working >>>>>> Group of the IETF. >>>>>>=20 >>>>>> Title : An Architecture for Media Recording using the >>>>>> Session Initiation Protocol >>>>>> Author(s) : Andrew Hutton >>>>>> Leon Portman >>>>>> Rajnish Jain >>>>>> Ken Rehor >>>>>> Filename : draft-ietf-siprec-architecture-04.txt >>>>>> Pages : 16 >>>>>> Date : 2012-03-12 >>>>>>=20 >>>>>> Session recording is a critical requirement in many = communications >>>>>> environments such as call centers and financial trading. In some >>>>>> of these environments, all calls must be recorded for regulatory, >>>>>> compliance, and consumer protection reasons. Recording of a >>>>>> session is typically performed by sending a copy of a media = stream >>>>>> to a recording device. This document describes architectures for >>>>>> deploying session recording solutions in an environment which is >>>>>> based on the Session Initiation Protocol (SIP). >>>>>>=20 >>>>>>=20 >>>>>> A URL for this Internet-Draft is: >>>>>> = http://www.ietf.org/internet-drafts/draft-ietf-siprec-architecture- >>>>>> 04.txt >>>>>>=20 >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>=20 >>>>>> This Internet-Draft can be retrieved at: >>>>>> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-architecture- >> 04. >>>>>> txt >>>>>>=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 >=20 From pravindran@sonusnet.com Fri Mar 16 11:38:40 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC8121E806D for ; Fri, 16 Mar 2012 11:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.65 X-Spam-Level: X-Spam-Status: No, score=-4.65 tagged_above=-999 required=5 tests=[AWL=1.949, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qs+mTHpM3RF8 for ; Fri, 16 Mar 2012 11:38:38 -0700 (PDT) Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC2C21E8073 for ; Fri, 16 Mar 2012 11:38:38 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKT2OIrZfNlOGZ63bNwcQv1Ru0S1vB4hZ+@postini.com; Fri, 16 Mar 2012 11:38:38 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 16 Mar 2012 14:38:48 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Sat, 17 Mar 2012 00:08:32 +0530 From: "Ravindran, Parthasarathi" To: Leon Portman Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt Thread-Index: AQHNAFN+7jAuVLtiI0aefxoa4INav5ZoBQaAgAHS3hCAAwPfAIAAXQiA//+pRgCAAFzf8P//pzyAgABcY7A= Date: Fri, 16 Mar 2012 18:38:32 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB37@inba-mail01.sonusnet.com> References: <20120312132433.19581.40959.idtracker@ietfa.amsl.com> <07465C1D981ABC41A344374066AE1A2C39DAF8C0A7@TLVMBX01.nice.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FCACA@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAD4@inba-mail01.sonusnet.com> <02E25602-BB51-4091-95E3-A5475AB4B85D@gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAF3@inba-mail01.sonusnet.com> <96F77B6A-C42F-4C45-BF24-F6BF9CCAE026@gmail.com> In-Reply-To: <96F77B6A-C42F-4C45-BF24-F6BF9CCAE026@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 18:38:40 -0000 Leon, I agree with you. Let architecture document mentions only that the mechanis= m is required to identify the communication session in SRS-initiated callfl= ow and exact mechanism will be defined in protocol draft. Thanks Partha >-----Original Message----- >From: Leon Portman [mailto:leon.portman@gmail.com] >Sent: Friday, March 16, 2012 11:51 PM >To: Ravindran, Parthasarathi >Cc: Leon Portman; siprec@ietf.org >Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt > >The main question then, if it will be required to be defined in the >protocol draft and we can keep architecture draft at high level in order >to move forward > >Leon > >On Mar 16, 2012, at 8:16 PM, "Ravindran, Parthasarathi" > wrote: > >> Leon, >> >> I agree with you that session-id solves the reported problem. >> >> As you might know, Session id IETF WG namely INSIPID is in the very >early stage and number of drafts under discussion for IETF-83 are listed >in http://www.ietf.org/mail-archive/web/insipid/current/msg00005.html. >IMO, creating session-id dependency will delay SIPREC deliverable. We >will brainstorm more to find some way without session-id if exists. >> >> Thanks >> Partha >> >>> -----Original Message----- >>> From: Leon Portman [mailto:leon.portman@gmail.com] >>> Sent: Friday, March 16, 2012 11:36 PM >>> To: Ravindran, Parthasarathi >>> Cc: Leon Portman; siprec@ietf.org >>> Subject: Re: [siprec] I-D Action: >>> draft-ietf-siprec-architecture-04.txt >>> >>> Partha, >>> >>> I completely agree with you. Session identification is one of the >>> main pain points today. May be Global session ID work will help here? >>> http://tools.ietf.org/html/draft-kaplan-dispatch-session-id-01 >>> >>> Leon >>> >>> On Mar 16, 2012, at 7:59 PM, "Ravindran, Parthasarathi" >>> wrote: >>> >>>> Leon, >>>> >>>> I agree with you that it is the way proprietary SIP recording works >>> today. For each SRS initiated callflow, unique-id of a session is >>> generated by PBX driven or CTI, SRC is forced to develop multiple >>> solutions accordingly as there is a lack of standard mechanism. I >>> have concern because SRS initiated without any specific >>> identification continue the same trend of today's proprietary >>> recording solution. I wish to see some well-defined protocol >>> mechanism from SRS to SRC to identity the session which has to >>> recorded. Please let me know your opinion. >>>> >>>> As you have listed number of mechanism, I'm fine in case we nailed >>> down to one of the mechanism as standard in the worst case. >>>> >>>> Thanks >>>> Partha >>>> >>>>> -----Original Message----- >>>>> From: Leon Portman [mailto:leon.portman@gmail.com] >>>>> Sent: Friday, March 16, 2012 11:14 PM >>>>> To: Ravindran, Parthasarathi >>>>> Cc: Leon Portman; siprec@ietf.org >>>>> Subject: Re: [siprec] I-D Action: >>>>> draft-ietf-siprec-architecture-04.txt >>>>> >>>>> Partha Hi >>>>> >>>>> The ways of identification of CS to be recorded for SRS initiated >>>>> flows are very dependent on actual SRC implementation. >>>>> For example, if SRC is PBX, it can be even CTI call id, >>>>> participants ids, DNS name of end point etc. >>>>> >>>>> For gateways it can be IP and PORT of RTP stream for example. >>>>> >>>>> This what i meant that it is very defendant on SRC and on the way >>>>> how SRS knows about CSs. >>>>> >>>>> Regards >>>>> >>>>> Leon >>>>> >>>>> On Mar 14, 2012, at 4:12 PM, "Ravindran, Parthasarathi" >>>>> wrote: >>>>> >>>>>> Leon, >>>>>> >>>>>> Could you please explain in detail about Sec 3.2.2 update >>>>>> >>>>>> " o The actual mechanism of the identification is depends on >SRC >>>>>> policy." >>>>>> >>>>>> Thanks >>>>>> partha >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>>>> Behalf Of Leon Portman >>>>>>> Sent: Tuesday, March 13, 2012 9:20 PM >>>>>>> To: siprec@ietf.org >>>>>>> Subject: Re: [siprec] I-D Action: >>>>>>> draft-ietf-siprec-architecture-04.txt >>>>>>> >>>>>>> Main changes. They are mainly consist from Gonzalo and other >>>>>>> mailing lists comments. >>>>>>> >>>>>>> 1. Definitions: Adding recording unaware UA definition and fixing >>>>>>> some other definitions 2. Consistent abbreviation usage in the >>>>> document 3. >>>>>>> Figures fixes 4. Adding policy mentions in Endpoint as SRC 5. >>>>>>> Removing WEBRTC mentions 6. Adding more descriptions in SRS >>>>>>> initiated flows 7.Adding support for RS without metadata >>>>>>> >>>>>>> There are some small typo mistakes in v04. I have already fixed >>>>>>> them and will update in next version >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Leon >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>>>> Behalf Of internet-drafts@ietf.org >>>>>>> Sent: Monday, March 12, 2012 3:25 PM >>>>>>> To: i-d-announce@ietf.org >>>>>>> Cc: siprec@ietf.org >>>>>>> Subject: [siprec] I-D Action: >>>>>>> draft-ietf-siprec-architecture-04.txt >>>>>>> >>>>>>> >>>>>>> A New Internet-Draft is available from the on-line >>>>>>> Internet-Drafts directories. This draft is a work item of the SIP >>>>>>> Recording Working Group of the IETF. >>>>>>> >>>>>>> Title : An Architecture for Media Recording using >the >>>>>>> Session Initiation Protocol >>>>>>> Author(s) : Andrew Hutton >>>>>>> Leon Portman >>>>>>> Rajnish Jain >>>>>>> Ken Rehor >>>>>>> Filename : draft-ietf-siprec-architecture-04.txt >>>>>>> Pages : 16 >>>>>>> Date : 2012-03-12 >>>>>>> >>>>>>> Session recording is a critical requirement in many >>>>>>> communications environments such as call centers and financial >>>>>>> trading. In some of these environments, all calls must be >>>>>>> recorded for regulatory, compliance, and consumer protection >>>>>>> reasons. Recording of a session is typically performed by >>>>>>> sending a copy of a media stream to a recording device. This >>>>>>> document describes architectures for deploying session recording >>>>>>> solutions in an environment which is based on the Session >Initiation Protocol (SIP). >>>>>>> >>>>>>> >>>>>>> A URL for this Internet-Draft is: >>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-siprec-architectur >>>>>>> e- >>>>>>> 04.txt >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> This Internet-Draft can be retrieved at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-architecture >>>>>>> - >>> 04. >>>>>>> txt >>>>>>> >>>>>>> _______________________________________________ >>>>>>> siprec mailing list >>>>>>> siprec@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>> _______________________________________________ >>>>>>> siprec mailing list >>>>>>> siprec@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>> _______________________________________________ >>>>>> siprec mailing list >>>>>> siprec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >> From andrew.hutton@siemens-enterprise.com Mon Mar 19 06:50:04 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8F221F863E for ; Mon, 19 Mar 2012 06:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeDaND8xAkri for ; Mon, 19 Mar 2012 06:50:02 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 2939421F862B for ; Mon, 19 Mar 2012 06:50:01 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 2CE9A23F04A8; Mon, 19 Mar 2012 14:50:00 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 19 Mar 2012 14:50:00 +0100 From: "Hutton, Andrew" To: "Ravindran, Parthasarathi" , Leon Portman Date: Mon, 19 Mar 2012 14:49:57 +0100 Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt Thread-Index: AQHNAFN+7jAuVLtiI0aefxoa4INav5ZoBQaAgAHS3hCAAwPfAIAAXQiA//+pRgCAAFzf8P//pzyAgABcY7CABGesgA== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31296AE1E00@MCHP058A.global-ad.net> References: <20120312132433.19581.40959.idtracker@ietfa.amsl.com> <07465C1D981ABC41A344374066AE1A2C39DAF8C0A7@TLVMBX01.nice.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FCACA@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAD4@inba-mail01.sonusnet.com> <02E25602-BB51-4091-95E3-A5475AB4B85D@gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAF3@inba-mail01.sonusnet.com> <96F77B6A-C42F-4C45-BF24-F6BF9CCAE026@gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB37@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB37@inba-mail01.sonusnet.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] I-D Action: draft-ietf-siprec-architecture-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 13:50:04 -0000 Hi Leon, I expected the bullet in section 3.2.2 stating "Identify the session that i= s to be recorded - Possibly using the Join header" to be removed in this la= test update. The issue was raised by Gonzalo and in my response to those on= the mailing list. (See http://www.ietf.org/mail-archive/web/siprec/current= /msg03125.html). In previous discussion I thought we had agreed at least in some scenarios t= here was no need to define such a mechanism as it would be up to policy at = the SRC and for example in the persistent recording case there may not even= be a CS at the time the RS is established. Regards Andy > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ravindran, Parthasarathi > Sent: 16 March 2012 18:39 > To: Leon Portman > Cc: siprec@ietf.org > Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt >=20 > Leon, >=20 > I agree with you. Let architecture document mentions only that the > mechanism is required to identify the communication session in SRS- > initiated callflow and exact mechanism will be defined in protocol > draft. >=20 > Thanks > Partha >=20 > >-----Original Message----- > >From: Leon Portman [mailto:leon.portman@gmail.com] > >Sent: Friday, March 16, 2012 11:51 PM > >To: Ravindran, Parthasarathi > >Cc: Leon Portman; siprec@ietf.org > >Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture- > 04.txt > > > >The main question then, if it will be required to be defined in the > >protocol draft and we can keep architecture draft at high level in > order > >to move forward > > > >Leon > > > >On Mar 16, 2012, at 8:16 PM, "Ravindran, Parthasarathi" > > wrote: > > > >> Leon, > >> > >> I agree with you that session-id solves the reported problem. > >> > >> As you might know, Session id IETF WG namely INSIPID is in the very > >early stage and number of drafts under discussion for IETF-83 are > listed > >in http://www.ietf.org/mail-archive/web/insipid/current/msg00005.html. > >IMO, creating session-id dependency will delay SIPREC deliverable. We > >will brainstorm more to find some way without session-id if exists. > >> > >> Thanks > >> Partha > >> > >>> -----Original Message----- > >>> From: Leon Portman [mailto:leon.portman@gmail.com] > >>> Sent: Friday, March 16, 2012 11:36 PM > >>> To: Ravindran, Parthasarathi > >>> Cc: Leon Portman; siprec@ietf.org > >>> Subject: Re: [siprec] I-D Action: > >>> draft-ietf-siprec-architecture-04.txt > >>> > >>> Partha, > >>> > >>> I completely agree with you. Session identification is one of the > >>> main pain points today. May be Global session ID work will help > here? > >>> http://tools.ietf.org/html/draft-kaplan-dispatch-session-id-01 > >>> > >>> Leon > >>> > >>> On Mar 16, 2012, at 7:59 PM, "Ravindran, Parthasarathi" > >>> wrote: > >>> > >>>> Leon, > >>>> > >>>> I agree with you that it is the way proprietary SIP recording > works > >>> today. For each SRS initiated callflow, unique-id of a session is > >>> generated by PBX driven or CTI, SRC is forced to develop multiple > >>> solutions accordingly as there is a lack of standard mechanism. I > >>> have concern because SRS initiated without any specific > >>> identification continue the same trend of today's proprietary > >>> recording solution. I wish to see some well-defined protocol > >>> mechanism from SRS to SRC to identity the session which has to > >>> recorded. Please let me know your opinion. > >>>> > >>>> As you have listed number of mechanism, I'm fine in case we nailed > >>> down to one of the mechanism as standard in the worst case. > >>>> > >>>> Thanks > >>>> Partha > >>>> > >>>>> -----Original Message----- > >>>>> From: Leon Portman [mailto:leon.portman@gmail.com] > >>>>> Sent: Friday, March 16, 2012 11:14 PM > >>>>> To: Ravindran, Parthasarathi > >>>>> Cc: Leon Portman; siprec@ietf.org > >>>>> Subject: Re: [siprec] I-D Action: > >>>>> draft-ietf-siprec-architecture-04.txt > >>>>> > >>>>> Partha Hi > >>>>> > >>>>> The ways of identification of CS to be recorded for SRS > initiated > >>>>> flows are very dependent on actual SRC implementation. > >>>>> For example, if SRC is PBX, it can be even CTI call id, > >>>>> participants ids, DNS name of end point etc. > >>>>> > >>>>> For gateways it can be IP and PORT of RTP stream for example. > >>>>> > >>>>> This what i meant that it is very defendant on SRC and on the way > >>>>> how SRS knows about CSs. > >>>>> > >>>>> Regards > >>>>> > >>>>> Leon > >>>>> > >>>>> On Mar 14, 2012, at 4:12 PM, "Ravindran, Parthasarathi" > >>>>> wrote: > >>>>> > >>>>>> Leon, > >>>>>> > >>>>>> Could you please explain in detail about Sec 3.2.2 update > >>>>>> > >>>>>> " o The actual mechanism of the identification is depends on > >SRC > >>>>>> policy." > >>>>>> > >>>>>> Thanks > >>>>>> partha > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > >>>>>>> Behalf Of Leon Portman > >>>>>>> Sent: Tuesday, March 13, 2012 9:20 PM > >>>>>>> To: siprec@ietf.org > >>>>>>> Subject: Re: [siprec] I-D Action: > >>>>>>> draft-ietf-siprec-architecture-04.txt > >>>>>>> > >>>>>>> Main changes. They are mainly consist from Gonzalo and other > >>>>>>> mailing lists comments. > >>>>>>> > >>>>>>> 1. Definitions: Adding recording unaware UA definition and > fixing > >>>>>>> some other definitions 2. Consistent abbreviation usage in the > >>>>> document 3. > >>>>>>> Figures fixes 4. Adding policy mentions in Endpoint as SRC 5. > >>>>>>> Removing WEBRTC mentions 6. Adding more descriptions in SRS > >>>>>>> initiated flows 7.Adding support for RS without metadata > >>>>>>> > >>>>>>> There are some small typo mistakes in v04. I have already fixed > >>>>>>> them and will update in next version > >>>>>>> > >>>>>>> Regards > >>>>>>> > >>>>>>> Leon > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > >>>>>>> Behalf Of internet-drafts@ietf.org > >>>>>>> Sent: Monday, March 12, 2012 3:25 PM > >>>>>>> To: i-d-announce@ietf.org > >>>>>>> Cc: siprec@ietf.org > >>>>>>> Subject: [siprec] I-D Action: > >>>>>>> draft-ietf-siprec-architecture-04.txt > >>>>>>> > >>>>>>> > >>>>>>> A New Internet-Draft is available from the on-line > >>>>>>> Internet-Drafts directories. This draft is a work item of the > SIP > >>>>>>> Recording Working Group of the IETF. > >>>>>>> > >>>>>>> Title : An Architecture for Media Recording using > >the > >>>>>>> Session Initiation Protocol > >>>>>>> Author(s) : Andrew Hutton > >>>>>>> Leon Portman > >>>>>>> Rajnish Jain > >>>>>>> Ken Rehor > >>>>>>> Filename : draft-ietf-siprec-architecture-04.txt > >>>>>>> Pages : 16 > >>>>>>> Date : 2012-03-12 > >>>>>>> > >>>>>>> Session recording is a critical requirement in many > >>>>>>> communications environments such as call centers and financial > >>>>>>> trading. In some of these environments, all calls must be > >>>>>>> recorded for regulatory, compliance, and consumer protection > >>>>>>> reasons. Recording of a session is typically performed by > >>>>>>> sending a copy of a media stream to a recording device. This > >>>>>>> document describes architectures for deploying session > recording > >>>>>>> solutions in an environment which is based on the Session > >Initiation Protocol (SIP). > >>>>>>> > >>>>>>> > >>>>>>> A URL for this Internet-Draft is: > >>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-siprec- > architectur > >>>>>>> e- > >>>>>>> 04.txt > >>>>>>> > >>>>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>>>> > >>>>>>> This Internet-Draft can be retrieved at: > >>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec- > architecture > >>>>>>> - > >>> 04. > >>>>>>> txt > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> siprec mailing list > >>>>>>> siprec@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>>> _______________________________________________ > >>>>>>> siprec mailing list > >>>>>>> siprec@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>> _______________________________________________ > >>>>>> siprec mailing list > >>>>>> siprec@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>> > >> >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pravindran@sonusnet.com Mon Mar 19 07:01:05 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C7D21F86E0 for ; Mon, 19 Mar 2012 07:01:05 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IO8eQwAxMLPo for ; Mon, 19 Mar 2012 07:01:05 -0700 (PDT) Received: from na3sys010aog106.obsmtp.com (na3sys010aog106.obsmtp.com [74.125.245.80]) by ietfa.amsl.com (Postfix) with ESMTP id 565EF21F86DE for ; Mon, 19 Mar 2012 07:01:04 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob106.postini.com ([74.125.244.12]) with SMTP ID DSNKT2c8H2Yeis1+1QsJ3jWKggOk6KDopysz@postini.com; Mon, 19 Mar 2012 07:01:04 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 19 Mar 2012 10:01:16 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Mon, 19 Mar 2012 19:30:58 +0530 From: "Ravindran, Parthasarathi" To: "Hutton, Andrew" , Leon Portman Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt Thread-Index: AQHNAFN+7jAuVLtiI0aefxoa4INav5ZoBQaAgAHS3hCAAwPfAIAAXQiA//+pRgCAAFzf8P//pzyAgABcY7CABGesgIAABBqQ Date: Mon, 19 Mar 2012 14:00:57 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E1FFAE6@inba-mail01.sonusnet.com> References: <20120312132433.19581.40959.idtracker@ietfa.amsl.com> <07465C1D981ABC41A344374066AE1A2C39DAF8C0A7@TLVMBX01.nice.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FCACA@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAD4@inba-mail01.sonusnet.com> <02E25602-BB51-4091-95E3-A5475AB4B85D@gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAF3@inba-mail01.sonusnet.com> <96F77B6A-C42F-4C45-BF24-F6BF9CCAE026@gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB37@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E31296AE1E00@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31296AE1E00@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.61] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:01:06 -0000 Hi Andy, As I mentioned in the below mail, the policy of SRC should not decide what = recording has to be started rather it has to be clearly mentioned by SRS an= d it will leads to interop issue as SRS has to expect recording based on di= fferent SRC implementation. In case CS id is not generic enough for SRS-initiated callflow. Let us work= for the list of possible standard mechanism required=20 1) Communication Session-id=20 2) participant 3) stream??? I still think that the exact SRS-initiated recording mechanism has to be me= ntioned in the protocol draft rather than in the architecture document. Thanks Partha >-----Original Message----- >From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] >Sent: Monday, March 19, 2012 7:20 PM >To: Ravindran, Parthasarathi; Leon Portman >Cc: siprec@ietf.org >Subject: RE: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt > >Hi Leon, > >I expected the bullet in section 3.2.2 stating "Identify the session >that is to be recorded - Possibly using the Join header" to be removed >in this latest update. The issue was raised by Gonzalo and in my >response to those on the mailing list. (See http://www.ietf.org/mail- >archive/web/siprec/current/msg03125.html). > >In previous discussion I thought we had agreed at least in some >scenarios there was no need to define such a mechanism as it would be up >to policy at the SRC and for example in the persistent recording case >there may not even be a CS at the time the RS is established. > >Regards >Andy > > > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Ravindran, Parthasarathi >> Sent: 16 March 2012 18:39 >> To: Leon Portman >> Cc: siprec@ietf.org >> Subject: Re: [siprec] I-D Action: >> draft-ietf-siprec-architecture-04.txt >> >> Leon, >> >> I agree with you. Let architecture document mentions only that the >> mechanism is required to identify the communication session in SRS- >> initiated callflow and exact mechanism will be defined in protocol >> draft. >> >> Thanks >> Partha >> >> >-----Original Message----- >> >From: Leon Portman [mailto:leon.portman@gmail.com] >> >Sent: Friday, March 16, 2012 11:51 PM >> >To: Ravindran, Parthasarathi >> >Cc: Leon Portman; siprec@ietf.org >> >Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture- >> 04.txt >> > >> >The main question then, if it will be required to be defined in the >> >protocol draft and we can keep architecture draft at high level in >> order >> >to move forward >> > >> >Leon >> > >> >On Mar 16, 2012, at 8:16 PM, "Ravindran, Parthasarathi" >> > wrote: >> > >> >> Leon, >> >> >> >> I agree with you that session-id solves the reported problem. >> >> >> >> As you might know, Session id IETF WG namely INSIPID is in the very >> >early stage and number of drafts under discussion for IETF-83 are >> listed >> >in http://www.ietf.org/mail- >archive/web/insipid/current/msg00005.html. >> >IMO, creating session-id dependency will delay SIPREC deliverable. We >> >will brainstorm more to find some way without session-id if exists. >> >> >> >> Thanks >> >> Partha >> >> >> >>> -----Original Message----- >> >>> From: Leon Portman [mailto:leon.portman@gmail.com] >> >>> Sent: Friday, March 16, 2012 11:36 PM >> >>> To: Ravindran, Parthasarathi >> >>> Cc: Leon Portman; siprec@ietf.org >> >>> Subject: Re: [siprec] I-D Action: >> >>> draft-ietf-siprec-architecture-04.txt >> >>> >> >>> Partha, >> >>> >> >>> I completely agree with you. Session identification is one of the >> >>> main pain points today. May be Global session ID work will help >> here? >> >>> http://tools.ietf.org/html/draft-kaplan-dispatch-session-id-01 >> >>> >> >>> Leon >> >>> >> >>> On Mar 16, 2012, at 7:59 PM, "Ravindran, Parthasarathi" >> >>> wrote: >> >>> >> >>>> Leon, >> >>>> >> >>>> I agree with you that it is the way proprietary SIP recording >> works >> >>> today. For each SRS initiated callflow, unique-id of a session is >> >>> generated by PBX driven or CTI, SRC is forced to develop multiple >> >>> solutions accordingly as there is a lack of standard mechanism. I >> >>> have concern because SRS initiated without any specific >> >>> identification continue the same trend of today's proprietary >> >>> recording solution. I wish to see some well-defined protocol >> >>> mechanism from SRS to SRC to identity the session which has to >> >>> recorded. Please let me know your opinion. >> >>>> >> >>>> As you have listed number of mechanism, I'm fine in case we >> >>>> nailed >> >>> down to one of the mechanism as standard in the worst case. >> >>>> >> >>>> Thanks >> >>>> Partha >> >>>> >> >>>>> -----Original Message----- >> >>>>> From: Leon Portman [mailto:leon.portman@gmail.com] >> >>>>> Sent: Friday, March 16, 2012 11:14 PM >> >>>>> To: Ravindran, Parthasarathi >> >>>>> Cc: Leon Portman; siprec@ietf.org >> >>>>> Subject: Re: [siprec] I-D Action: >> >>>>> draft-ietf-siprec-architecture-04.txt >> >>>>> >> >>>>> Partha Hi >> >>>>> >> >>>>> The ways of identification of CS to be recorded for SRS >> initiated >> >>>>> flows are very dependent on actual SRC implementation. >> >>>>> For example, if SRC is PBX, it can be even CTI call id, >> >>>>> participants ids, DNS name of end point etc. >> >>>>> >> >>>>> For gateways it can be IP and PORT of RTP stream for example. >> >>>>> >> >>>>> This what i meant that it is very defendant on SRC and on the >> >>>>> way how SRS knows about CSs. >> >>>>> >> >>>>> Regards >> >>>>> >> >>>>> Leon >> >>>>> >> >>>>> On Mar 14, 2012, at 4:12 PM, "Ravindran, Parthasarathi" >> >>>>> wrote: >> >>>>> >> >>>>>> Leon, >> >>>>>> >> >>>>>> Could you please explain in detail about Sec 3.2.2 update >> >>>>>> >> >>>>>> " o The actual mechanism of the identification is depends on >> >SRC >> >>>>>> policy." >> >>>>>> >> >>>>>> Thanks >> >>>>>> partha >> >>>>>> >> >>>>>>> -----Original Message----- >> >>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] >> On >> >>>>>>> Behalf Of Leon Portman >> >>>>>>> Sent: Tuesday, March 13, 2012 9:20 PM >> >>>>>>> To: siprec@ietf.org >> >>>>>>> Subject: Re: [siprec] I-D Action: >> >>>>>>> draft-ietf-siprec-architecture-04.txt >> >>>>>>> >> >>>>>>> Main changes. They are mainly consist from Gonzalo and other >> >>>>>>> mailing lists comments. >> >>>>>>> >> >>>>>>> 1. Definitions: Adding recording unaware UA definition and >> fixing >> >>>>>>> some other definitions 2. Consistent abbreviation usage in the >> >>>>> document 3. >> >>>>>>> Figures fixes 4. Adding policy mentions in Endpoint as SRC 5. >> >>>>>>> Removing WEBRTC mentions 6. Adding more descriptions in SRS >> >>>>>>> initiated flows 7.Adding support for RS without metadata >> >>>>>>> >> >>>>>>> There are some small typo mistakes in v04. I have already >> >>>>>>> fixed them and will update in next version >> >>>>>>> >> >>>>>>> Regards >> >>>>>>> >> >>>>>>> Leon >> >>>>>>> >> >>>>>>> -----Original Message----- >> >>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] >> On >> >>>>>>> Behalf Of internet-drafts@ietf.org >> >>>>>>> Sent: Monday, March 12, 2012 3:25 PM >> >>>>>>> To: i-d-announce@ietf.org >> >>>>>>> Cc: siprec@ietf.org >> >>>>>>> Subject: [siprec] I-D Action: >> >>>>>>> draft-ietf-siprec-architecture-04.txt >> >>>>>>> >> >>>>>>> >> >>>>>>> A New Internet-Draft is available from the on-line >> >>>>>>> Internet-Drafts directories. This draft is a work item of the >> SIP >> >>>>>>> Recording Working Group of the IETF. >> >>>>>>> >> >>>>>>> Title : An Architecture for Media Recording using >> >the >> >>>>>>> Session Initiation Protocol >> >>>>>>> Author(s) : Andrew Hutton >> >>>>>>> Leon Portman >> >>>>>>> Rajnish Jain >> >>>>>>> Ken Rehor >> >>>>>>> Filename : draft-ietf-siprec-architecture-04.txt >> >>>>>>> Pages : 16 >> >>>>>>> Date : 2012-03-12 >> >>>>>>> >> >>>>>>> Session recording is a critical requirement in many >> >>>>>>> communications environments such as call centers and financial >> >>>>>>> trading. In some of these environments, all calls must be >> >>>>>>> recorded for regulatory, compliance, and consumer protection >> >>>>>>> reasons. Recording of a session is typically performed by >> >>>>>>> sending a copy of a media stream to a recording device. This >> >>>>>>> document describes architectures for deploying session >> recording >> >>>>>>> solutions in an environment which is based on the Session >> >Initiation Protocol (SIP). >> >>>>>>> >> >>>>>>> >> >>>>>>> A URL for this Internet-Draft is: >> >>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-siprec- >> architectur >> >>>>>>> e- >> >>>>>>> 04.txt >> >>>>>>> >> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >> >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >> >>>>>>> >> >>>>>>> This Internet-Draft can be retrieved at: >> >>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec- >> architecture >> >>>>>>> - >> >>> 04. >> >>>>>>> txt >> >>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> siprec mailing list >> >>>>>>> siprec@ietf.org >> >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >> >>>>>>> _______________________________________________ >> >>>>>>> siprec mailing list >> >>>>>>> siprec@ietf.org >> >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >> >>>>>> _______________________________________________ >> >>>>>> siprec mailing list >> >>>>>> siprec@ietf.org >> >>>>>> https://www.ietf.org/mailman/listinfo/siprec >> >>>> >> >> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec From Leon.Portman@nice.com Mon Mar 19 07:10:23 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDCA21F86F6 for ; Mon, 19 Mar 2012 07:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUyMLitGMTda for ; Mon, 19 Mar 2012 07:10:21 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC5821F86A8 for ; Mon, 19 Mar 2012 07:10:21 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Mon, 19 Mar 2012 16:10:19 +0200 From: Leon Portman To: "Ravindran, Parthasarathi" , "Hutton, Andrew" , Leon Portman Date: Mon, 19 Mar 2012 16:10:18 +0200 Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt Thread-Index: AQHNAFN+7jAuVLtiI0aefxoa4INav5ZoBQaAgAHS3hCAAwPfAIAAXQiA//+pRgCAAFzf8P//pzyAgABcY7CABGesgIAABBqQgAAEHfA= Message-ID: <07465C1D981ABC41A344374066AE1A2C39DAFFEC01@TLVMBX01.nice.com> References: <20120312132433.19581.40959.idtracker@ietfa.amsl.com> <07465C1D981ABC41A344374066AE1A2C39DAF8C0A7@TLVMBX01.nice.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FCACA@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAD4@inba-mail01.sonusnet.com> <02E25602-BB51-4091-95E3-A5475AB4B85D@gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAF3@inba-mail01.sonusnet.com> <96F77B6A-C42F-4C45-BF24-F6BF9CCAE026@gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB37@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E31296AE1E00@MCHP058A.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C0E1FFAE6@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E1FFAE6@inba-mail01.sonusnet.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] I-D Action: draft-ietf-siprec-architecture-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:10:23 -0000 Actually these are two separate issues, one is how to identify the communic= ation session, and second how to indicate it in RS invite (FROM SRS to SRC)= .=20 Back to Andy comment, even for persistent use case, SRS will send re-invite= with some CS identifier so we need to have such mechanism. My understandin= g from the below thread was to add the policy mentioning and not just to co= mpletely remove the mechanism mentioning. I am ok with both options.=20 I will remove Join example it in the next update. Regards Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Ravindran, Parthasarathi Sent: Monday, March 19, 2012 4:01 PM To: Hutton, Andrew; Leon Portman Cc: siprec@ietf.org Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt Hi Andy, As I mentioned in the below mail, the policy of SRC should not decide what = recording has to be started rather it has to be clearly mentioned by SRS an= d it will leads to interop issue as SRS has to expect recording based on di= fferent SRC implementation. In case CS id is not generic enough for SRS-initiated callflow. Let us work= for the list of possible standard mechanism required=20 1) Communication Session-id 2) participant 3) stream??? I still think that the exact SRS-initiated recording mechanism has to be me= ntioned in the protocol draft rather than in the architecture document. Thanks Partha >-----Original Message----- >From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] >Sent: Monday, March 19, 2012 7:20 PM >To: Ravindran, Parthasarathi; Leon Portman >Cc: siprec@ietf.org >Subject: RE: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt > >Hi Leon, > >I expected the bullet in section 3.2.2 stating "Identify the session=20 >that is to be recorded - Possibly using the Join header" to be removed=20 >in this latest update. The issue was raised by Gonzalo and in my=20 >response to those on the mailing list. (See http://www.ietf.org/mail-=20 >archive/web/siprec/current/msg03125.html). > >In previous discussion I thought we had agreed at least in some=20 >scenarios there was no need to define such a mechanism as it would be=20 >up to policy at the SRC and for example in the persistent recording=20 >case there may not even be a CS at the time the RS is established. > >Regards >Andy > > > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >> Behalf Of Ravindran, Parthasarathi >> Sent: 16 March 2012 18:39 >> To: Leon Portman >> Cc: siprec@ietf.org >> Subject: Re: [siprec] I-D Action: >> draft-ietf-siprec-architecture-04.txt >> >> Leon, >> >> I agree with you. Let architecture document mentions only that the=20 >> mechanism is required to identify the communication session in SRS-=20 >> initiated callflow and exact mechanism will be defined in protocol=20 >> draft. >> >> Thanks >> Partha >> >> >-----Original Message----- >> >From: Leon Portman [mailto:leon.portman@gmail.com] >> >Sent: Friday, March 16, 2012 11:51 PM >> >To: Ravindran, Parthasarathi >> >Cc: Leon Portman; siprec@ietf.org >> >Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture- >> 04.txt >> > >> >The main question then, if it will be required to be defined in the=20 >> >protocol draft and we can keep architecture draft at high level in >> order >> >to move forward >> > >> >Leon >> > >> >On Mar 16, 2012, at 8:16 PM, "Ravindran, Parthasarathi" >> > wrote: >> > >> >> Leon, >> >> >> >> I agree with you that session-id solves the reported problem. >> >> >> >> As you might know, Session id IETF WG namely INSIPID is in the=20 >> >> very >> >early stage and number of drafts under discussion for IETF-83 are >> listed >> >in http://www.ietf.org/mail- >archive/web/insipid/current/msg00005.html. >> >IMO, creating session-id dependency will delay SIPREC deliverable.=20 >> >We will brainstorm more to find some way without session-id if exists. >> >> >> >> Thanks >> >> Partha >> >> >> >>> -----Original Message----- >> >>> From: Leon Portman [mailto:leon.portman@gmail.com] >> >>> Sent: Friday, March 16, 2012 11:36 PM >> >>> To: Ravindran, Parthasarathi >> >>> Cc: Leon Portman; siprec@ietf.org >> >>> Subject: Re: [siprec] I-D Action: >> >>> draft-ietf-siprec-architecture-04.txt >> >>> >> >>> Partha, >> >>> >> >>> I completely agree with you. Session identification is one of the=20 >> >>> main pain points today. May be Global session ID work will help >> here? >> >>> http://tools.ietf.org/html/draft-kaplan-dispatch-session-id-01 >> >>> >> >>> Leon >> >>> >> >>> On Mar 16, 2012, at 7:59 PM, "Ravindran, Parthasarathi" >> >>> wrote: >> >>> >> >>>> Leon, >> >>>> >> >>>> I agree with you that it is the way proprietary SIP recording >> works >> >>> today. For each SRS initiated callflow, unique-id of a session is=20 >> >>> generated by PBX driven or CTI, SRC is forced to develop multiple=20 >> >>> solutions accordingly as there is a lack of standard mechanism. =20 >> >>> I have concern because SRS initiated without any specific=20 >> >>> identification continue the same trend of today's proprietary=20 >> >>> recording solution. I wish to see some well-defined protocol=20 >> >>> mechanism from SRS to SRC to identity the session which has to=20 >> >>> recorded. Please let me know your opinion. >> >>>> >> >>>> As you have listed number of mechanism, I'm fine in case we=20 >> >>>> nailed >> >>> down to one of the mechanism as standard in the worst case. >> >>>> >> >>>> Thanks >> >>>> Partha >> >>>> >> >>>>> -----Original Message----- >> >>>>> From: Leon Portman [mailto:leon.portman@gmail.com] >> >>>>> Sent: Friday, March 16, 2012 11:14 PM >> >>>>> To: Ravindran, Parthasarathi >> >>>>> Cc: Leon Portman; siprec@ietf.org >> >>>>> Subject: Re: [siprec] I-D Action: >> >>>>> draft-ietf-siprec-architecture-04.txt >> >>>>> >> >>>>> Partha Hi >> >>>>> >> >>>>> The ways of identification of CS to be recorded for SRS >> initiated >> >>>>> flows are very dependent on actual SRC implementation. >> >>>>> For example, if SRC is PBX, it can be even CTI call id,=20 >> >>>>> participants ids, DNS name of end point etc. >> >>>>> >> >>>>> For gateways it can be IP and PORT of RTP stream for example. >> >>>>> >> >>>>> This what i meant that it is very defendant on SRC and on the=20 >> >>>>> way how SRS knows about CSs. >> >>>>> >> >>>>> Regards >> >>>>> >> >>>>> Leon >> >>>>> >> >>>>> On Mar 14, 2012, at 4:12 PM, "Ravindran, Parthasarathi" >> >>>>> wrote: >> >>>>> >> >>>>>> Leon, >> >>>>>> >> >>>>>> Could you please explain in detail about Sec 3.2.2 update >> >>>>>> >> >>>>>> " o The actual mechanism of the identification is depends on >> >SRC >> >>>>>> policy." >> >>>>>> >> >>>>>> Thanks >> >>>>>> partha >> >>>>>> >> >>>>>>> -----Original Message----- >> >>>>>>> From: siprec-bounces@ietf.org=20 >> >>>>>>> [mailto:siprec-bounces@ietf.org] >> On >> >>>>>>> Behalf Of Leon Portman >> >>>>>>> Sent: Tuesday, March 13, 2012 9:20 PM >> >>>>>>> To: siprec@ietf.org >> >>>>>>> Subject: Re: [siprec] I-D Action: >> >>>>>>> draft-ietf-siprec-architecture-04.txt >> >>>>>>> >> >>>>>>> Main changes. They are mainly consist from Gonzalo and other=20 >> >>>>>>> mailing lists comments. >> >>>>>>> >> >>>>>>> 1. Definitions: Adding recording unaware UA definition and >> fixing >> >>>>>>> some other definitions 2. Consistent abbreviation usage in=20 >> >>>>>>> the >> >>>>> document 3. >> >>>>>>> Figures fixes 4. Adding policy mentions in Endpoint as SRC 5. >> >>>>>>> Removing WEBRTC mentions 6. Adding more descriptions in SRS=20 >> >>>>>>> initiated flows 7.Adding support for RS without metadata >> >>>>>>> >> >>>>>>> There are some small typo mistakes in v04. I have already=20 >> >>>>>>> fixed them and will update in next version >> >>>>>>> >> >>>>>>> Regards >> >>>>>>> >> >>>>>>> Leon >> >>>>>>> >> >>>>>>> -----Original Message----- >> >>>>>>> From: siprec-bounces@ietf.org=20 >> >>>>>>> [mailto:siprec-bounces@ietf.org] >> On >> >>>>>>> Behalf Of internet-drafts@ietf.org >> >>>>>>> Sent: Monday, March 12, 2012 3:25 PM >> >>>>>>> To: i-d-announce@ietf.org >> >>>>>>> Cc: siprec@ietf.org >> >>>>>>> Subject: [siprec] I-D Action: >> >>>>>>> draft-ietf-siprec-architecture-04.txt >> >>>>>>> >> >>>>>>> >> >>>>>>> A New Internet-Draft is available from the on-line=20 >> >>>>>>> Internet-Drafts directories. This draft is a work item of the >> SIP >> >>>>>>> Recording Working Group of the IETF. >> >>>>>>> >> >>>>>>> Title : An Architecture for Media Recording using >> >the >> >>>>>>> Session Initiation Protocol >> >>>>>>> Author(s) : Andrew Hutton >> >>>>>>> Leon Portman >> >>>>>>> Rajnish Jain >> >>>>>>> Ken Rehor >> >>>>>>> Filename : draft-ietf-siprec-architecture-04.txt >> >>>>>>> Pages : 16 >> >>>>>>> Date : 2012-03-12 >> >>>>>>> >> >>>>>>> Session recording is a critical requirement in many=20 >> >>>>>>> communications environments such as call centers and=20 >> >>>>>>> financial trading. In some of these environments, all calls=20 >> >>>>>>> must be recorded for regulatory, compliance, and consumer=20 >> >>>>>>> protection reasons. Recording of a session is typically=20 >> >>>>>>> performed by sending a copy of a media stream to a recording=20 >> >>>>>>> device. This document describes architectures for deploying=20 >> >>>>>>> session >> recording >> >>>>>>> solutions in an environment which is based on the Session >> >Initiation Protocol (SIP). >> >>>>>>> >> >>>>>>> >> >>>>>>> A URL for this Internet-Draft is: >> >>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-siprec- >> architectur >> >>>>>>> e- >> >>>>>>> 04.txt >> >>>>>>> >> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >> >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >> >>>>>>> >> >>>>>>> This Internet-Draft can be retrieved at: >> >>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec- >> architecture >> >>>>>>> - >> >>> 04. >> >>>>>>> txt >> >>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> siprec mailing list >> >>>>>>> siprec@ietf.org >> >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >> >>>>>>> _______________________________________________ >> >>>>>>> siprec mailing list >> >>>>>>> siprec@ietf.org >> >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >> >>>>>> _______________________________________________ >> >>>>>> siprec mailing list >> >>>>>> siprec@ietf.org >> >>>>>> https://www.ietf.org/mailman/listinfo/siprec >> >>>> >> >> >> >> _______________________________________________ >> 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 Mar 19 07:17:07 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CCA21F8657 for ; Mon, 19 Mar 2012 07:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LR93mkHxbodJ for ; Mon, 19 Mar 2012 07:17:04 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 115D121F85F0 for ; Mon, 19 Mar 2012 07:17:04 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 7147E23F04CD; Mon, 19 Mar 2012 15:17:03 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 19 Mar 2012 15:17:03 +0100 From: "Hutton, Andrew" To: Leon Portman , "Ravindran, Parthasarathi" , Leon Portman Date: Mon, 19 Mar 2012 15:17:01 +0100 Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt Thread-Index: AQHNAFN+7jAuVLtiI0aefxoa4INav5ZoBQaAgAHS3hCAAwPfAIAAXQiA//+pRgCAAFzf8P//pzyAgABcY7CABGesgIAABBqQgAAEHfCAAAGZMA== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31296AE1E39@MCHP058A.global-ad.net> References: <20120312132433.19581.40959.idtracker@ietfa.amsl.com> <07465C1D981ABC41A344374066AE1A2C39DAF8C0A7@TLVMBX01.nice.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FCACA@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAD4@inba-mail01.sonusnet.com> <02E25602-BB51-4091-95E3-A5475AB4B85D@gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAF3@inba-mail01.sonusnet.com> <96F77B6A-C42F-4C45-BF24-F6BF9CCAE026@gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB37@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E31296AE1E00@MCHP058A.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C0E1FFAE6@inba-mail01.sonusnet.com> <07465C1D981ABC41A344374066AE1A2C39DAFFEC01@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C39DAFFEC01@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 Cc: "siprec@ietf.org" Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:17:07 -0000 See below. Regards Andy > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: 19 March 2012 14:10 > To: Ravindran, Parthasarathi; Hutton, Andrew; Leon Portman > Cc: siprec@ietf.org > Subject: RE: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt >=20 > Actually these are two separate issues, one is how to identify the > communication session, and second how to indicate it in RS invite (FROM > SRS to SRC). > Back to Andy comment, even for persistent use case, SRS will send re- > invite with some CS identifier so we need to have such mechanism.=20 [AndyH] - I assume this should be "SRS MAY send re-invite with some CS Iden= tifier..." because of course it can be the SRC that makes that decision bas= ed on policy. =20 >My > understanding from the below thread was to add the policy mentioning > and not just to completely remove the mechanism mentioning. I am ok > with both options. > I will remove Join example it in the next update. > [AndyH] - I think we should remove the mechanism from the architecture draf= t the "Join" example was there to promote discussion even before we had a p= rotocol draft and I think should now be removed. >=20 > Regards >=20 > Leon >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ravindran, Parthasarathi > Sent: Monday, March 19, 2012 4:01 PM > To: Hutton, Andrew; Leon Portman > Cc: siprec@ietf.org > Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt >=20 > Hi Andy, >=20 > As I mentioned in the below mail, the policy of SRC should not decide > what recording has to be started rather it has to be clearly mentioned > by SRS and it will leads to interop issue as SRS has to expect > recording based on different SRC implementation. >=20 > In case CS id is not generic enough for SRS-initiated callflow. Let us > work for the list of possible standard mechanism required >=20 > 1) Communication Session-id > 2) participant > 3) stream??? >=20 > I still think that the exact SRS-initiated recording mechanism has to > be mentioned in the protocol draft rather than in the architecture > document. >=20 > Thanks > Partha >=20 > >-----Original Message----- > >From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > >Sent: Monday, March 19, 2012 7:20 PM > >To: Ravindran, Parthasarathi; Leon Portman > >Cc: siprec@ietf.org > >Subject: RE: [siprec] I-D Action: draft-ietf-siprec-architecture- > 04.txt > > > >Hi Leon, > > > >I expected the bullet in section 3.2.2 stating "Identify the session > >that is to be recorded - Possibly using the Join header" to be removed > >in this latest update. The issue was raised by Gonzalo and in my > >response to those on the mailing list. (See http://www.ietf.org/mail- > >archive/web/siprec/current/msg03125.html). > > > >In previous discussion I thought we had agreed at least in some > >scenarios there was no need to define such a mechanism as it would be > >up to policy at the SRC and for example in the persistent recording > >case there may not even be a CS at the time the RS is established. > > > >Regards > >Andy > > > > > > > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Ravindran, Parthasarathi > >> Sent: 16 March 2012 18:39 > >> To: Leon Portman > >> Cc: siprec@ietf.org > >> Subject: Re: [siprec] I-D Action: > >> draft-ietf-siprec-architecture-04.txt > >> > >> Leon, > >> > >> I agree with you. Let architecture document mentions only that the > >> mechanism is required to identify the communication session in SRS- > >> initiated callflow and exact mechanism will be defined in protocol > >> draft. > >> > >> Thanks > >> Partha > >> > >> >-----Original Message----- > >> >From: Leon Portman [mailto:leon.portman@gmail.com] > >> >Sent: Friday, March 16, 2012 11:51 PM > >> >To: Ravindran, Parthasarathi > >> >Cc: Leon Portman; siprec@ietf.org > >> >Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture- > >> 04.txt > >> > > >> >The main question then, if it will be required to be defined in the > >> >protocol draft and we can keep architecture draft at high level in > >> order > >> >to move forward > >> > > >> >Leon > >> > > >> >On Mar 16, 2012, at 8:16 PM, "Ravindran, Parthasarathi" > >> > wrote: > >> > > >> >> Leon, > >> >> > >> >> I agree with you that session-id solves the reported problem. > >> >> > >> >> As you might know, Session id IETF WG namely INSIPID is in the > >> >> very > >> >early stage and number of drafts under discussion for IETF-83 are > >> listed > >> >in http://www.ietf.org/mail- > >archive/web/insipid/current/msg00005.html. > >> >IMO, creating session-id dependency will delay SIPREC deliverable. > >> >We will brainstorm more to find some way without session-id if > exists. > >> >> > >> >> Thanks > >> >> Partha > >> >> > >> >>> -----Original Message----- > >> >>> From: Leon Portman [mailto:leon.portman@gmail.com] > >> >>> Sent: Friday, March 16, 2012 11:36 PM > >> >>> To: Ravindran, Parthasarathi > >> >>> Cc: Leon Portman; siprec@ietf.org > >> >>> Subject: Re: [siprec] I-D Action: > >> >>> draft-ietf-siprec-architecture-04.txt > >> >>> > >> >>> Partha, > >> >>> > >> >>> I completely agree with you. Session identification is one of > the > >> >>> main pain points today. May be Global session ID work will help > >> here? > >> >>> http://tools.ietf.org/html/draft-kaplan-dispatch-session-id-01 > >> >>> > >> >>> Leon > >> >>> > >> >>> On Mar 16, 2012, at 7:59 PM, "Ravindran, Parthasarathi" > >> >>> wrote: > >> >>> > >> >>>> Leon, > >> >>>> > >> >>>> I agree with you that it is the way proprietary SIP recording > >> works > >> >>> today. For each SRS initiated callflow, unique-id of a session > is > >> >>> generated by PBX driven or CTI, SRC is forced to develop > multiple > >> >>> solutions accordingly as there is a lack of standard mechanism. > >> >>> I have concern because SRS initiated without any specific > >> >>> identification continue the same trend of today's proprietary > >> >>> recording solution. I wish to see some well-defined protocol > >> >>> mechanism from SRS to SRC to identity the session which has to > >> >>> recorded. Please let me know your opinion. > >> >>>> > >> >>>> As you have listed number of mechanism, I'm fine in case we > >> >>>> nailed > >> >>> down to one of the mechanism as standard in the worst case. > >> >>>> > >> >>>> Thanks > >> >>>> Partha > >> >>>> > >> >>>>> -----Original Message----- > >> >>>>> From: Leon Portman [mailto:leon.portman@gmail.com] > >> >>>>> Sent: Friday, March 16, 2012 11:14 PM > >> >>>>> To: Ravindran, Parthasarathi > >> >>>>> Cc: Leon Portman; siprec@ietf.org > >> >>>>> Subject: Re: [siprec] I-D Action: > >> >>>>> draft-ietf-siprec-architecture-04.txt > >> >>>>> > >> >>>>> Partha Hi > >> >>>>> > >> >>>>> The ways of identification of CS to be recorded for SRS > >> initiated > >> >>>>> flows are very dependent on actual SRC implementation. > >> >>>>> For example, if SRC is PBX, it can be even CTI call id, > >> >>>>> participants ids, DNS name of end point etc. > >> >>>>> > >> >>>>> For gateways it can be IP and PORT of RTP stream for example. > >> >>>>> > >> >>>>> This what i meant that it is very defendant on SRC and on the > >> >>>>> way how SRS knows about CSs. > >> >>>>> > >> >>>>> Regards > >> >>>>> > >> >>>>> Leon > >> >>>>> > >> >>>>> On Mar 14, 2012, at 4:12 PM, "Ravindran, Parthasarathi" > >> >>>>> wrote: > >> >>>>> > >> >>>>>> Leon, > >> >>>>>> > >> >>>>>> Could you please explain in detail about Sec 3.2.2 update > >> >>>>>> > >> >>>>>> " o The actual mechanism of the identification is depends > on > >> >SRC > >> >>>>>> policy." > >> >>>>>> > >> >>>>>> Thanks > >> >>>>>> partha > >> >>>>>> > >> >>>>>>> -----Original Message----- > >> >>>>>>> From: siprec-bounces@ietf.org > >> >>>>>>> [mailto:siprec-bounces@ietf.org] > >> On > >> >>>>>>> Behalf Of Leon Portman > >> >>>>>>> Sent: Tuesday, March 13, 2012 9:20 PM > >> >>>>>>> To: siprec@ietf.org > >> >>>>>>> Subject: Re: [siprec] I-D Action: > >> >>>>>>> draft-ietf-siprec-architecture-04.txt > >> >>>>>>> > >> >>>>>>> Main changes. They are mainly consist from Gonzalo and other > >> >>>>>>> mailing lists comments. > >> >>>>>>> > >> >>>>>>> 1. Definitions: Adding recording unaware UA definition and > >> fixing > >> >>>>>>> some other definitions 2. Consistent abbreviation usage in > >> >>>>>>> the > >> >>>>> document 3. > >> >>>>>>> Figures fixes 4. Adding policy mentions in Endpoint as SRC > 5. > >> >>>>>>> Removing WEBRTC mentions 6. Adding more descriptions in SRS > >> >>>>>>> initiated flows 7.Adding support for RS without metadata > >> >>>>>>> > >> >>>>>>> There are some small typo mistakes in v04. I have already > >> >>>>>>> fixed them and will update in next version > >> >>>>>>> > >> >>>>>>> Regards > >> >>>>>>> > >> >>>>>>> Leon > >> >>>>>>> > >> >>>>>>> -----Original Message----- > >> >>>>>>> From: siprec-bounces@ietf.org > >> >>>>>>> [mailto:siprec-bounces@ietf.org] > >> On > >> >>>>>>> Behalf Of internet-drafts@ietf.org > >> >>>>>>> Sent: Monday, March 12, 2012 3:25 PM > >> >>>>>>> To: i-d-announce@ietf.org > >> >>>>>>> Cc: siprec@ietf.org > >> >>>>>>> Subject: [siprec] I-D Action: > >> >>>>>>> draft-ietf-siprec-architecture-04.txt > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> A New Internet-Draft is available from the on-line > >> >>>>>>> Internet-Drafts directories. This draft is a work item of > the > >> SIP > >> >>>>>>> Recording Working Group of the IETF. > >> >>>>>>> > >> >>>>>>> Title : An Architecture for Media Recording using > >> >the > >> >>>>>>> Session Initiation Protocol > >> >>>>>>> Author(s) : Andrew Hutton > >> >>>>>>> Leon Portman > >> >>>>>>> Rajnish Jain > >> >>>>>>> Ken Rehor > >> >>>>>>> Filename : draft-ietf-siprec-architecture-04.txt > >> >>>>>>> Pages : 16 > >> >>>>>>> Date : 2012-03-12 > >> >>>>>>> > >> >>>>>>> Session recording is a critical requirement in many > >> >>>>>>> communications environments such as call centers and > >> >>>>>>> financial trading. In some of these environments, all calls > >> >>>>>>> must be recorded for regulatory, compliance, and consumer > >> >>>>>>> protection reasons. Recording of a session is typically > >> >>>>>>> performed by sending a copy of a media stream to a recording > >> >>>>>>> device. This document describes architectures for deploying > >> >>>>>>> session > >> recording > >> >>>>>>> solutions in an environment which is based on the Session > >> >Initiation Protocol (SIP). > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> A URL for this Internet-Draft is: > >> >>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-siprec- > >> architectur > >> >>>>>>> e- > >> >>>>>>> 04.txt > >> >>>>>>> > >> >>>>>>> Internet-Drafts are also available by anonymous FTP at: > >> >>>>>>> ftp://ftp.ietf.org/internet-drafts/ > >> >>>>>>> > >> >>>>>>> This Internet-Draft can be retrieved at: > >> >>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec- > >> architecture > >> >>>>>>> - > >> >>> 04. > >> >>>>>>> txt > >> >>>>>>> > >> >>>>>>> _______________________________________________ > >> >>>>>>> siprec mailing list > >> >>>>>>> siprec@ietf.org > >> >>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >> >>>>>>> _______________________________________________ > >> >>>>>>> siprec mailing list > >> >>>>>>> siprec@ietf.org > >> >>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >> >>>>>> _______________________________________________ > >> >>>>>> siprec mailing list > >> >>>>>> siprec@ietf.org > >> >>>>>> https://www.ietf.org/mailman/listinfo/siprec > >> >>>> > >> >> > >> > >> _______________________________________________ > >> 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 Mar 19 07:17:49 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA0221F85F3 for ; Mon, 19 Mar 2012 07:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMVUoUsE6-nE for ; Mon, 19 Mar 2012 07:17:48 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB5C21F85F0 for ; Mon, 19 Mar 2012 07:17:47 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Mon, 19 Mar 2012 16:17:46 +0200 From: Leon Portman To: "Hutton, Andrew" , "Ravindran, Parthasarathi" , Leon Portman Date: Mon, 19 Mar 2012 16:17:45 +0200 Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt Thread-Index: AQHNAFN+7jAuVLtiI0aefxoa4INav5ZoBQaAgAHS3hCAAwPfAIAAXQiA//+pRgCAAFzf8P//pzyAgABcY7CABGesgIAABBqQgAAEHfCAAAGZMIAAAV/w Message-ID: <07465C1D981ABC41A344374066AE1A2C39DAFFEC0A@TLVMBX01.nice.com> References: <20120312132433.19581.40959.idtracker@ietfa.amsl.com> <07465C1D981ABC41A344374066AE1A2C39DAF8C0A7@TLVMBX01.nice.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FCACA@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAD4@inba-mail01.sonusnet.com> <02E25602-BB51-4091-95E3-A5475AB4B85D@gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAF3@inba-mail01.sonusnet.com> <96F77B6A-C42F-4C45-BF24-F6BF9CCAE026@gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB37@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E31296AE1E00@MCHP058A.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C0E1FFAE6@inba-mail01.sonusnet.com> <07465C1D981ABC41A344374066AE1A2C39DAFFEC01@TLVMBX01.nice.com> <101C6067BEC68246B0C3F6843BCCC1E31296AE1E39@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31296AE1E39@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 Cc: "siprec@ietf.org" Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:17:49 -0000 Agree on both comments Leon -----Original Message----- From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com]=20 Sent: Monday, March 19, 2012 4:17 PM To: Leon Portman; Ravindran, Parthasarathi; Leon Portman Cc: siprec@ietf.org Subject: RE: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt See below. Regards Andy > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: 19 March 2012 14:10 > To: Ravindran, Parthasarathi; Hutton, Andrew; Leon Portman > Cc: siprec@ietf.org > Subject: RE: [siprec] I-D Action:=20 > draft-ietf-siprec-architecture-04.txt >=20 > Actually these are two separate issues, one is how to identify the=20 > communication session, and second how to indicate it in RS invite=20 > (FROM SRS to SRC). > Back to Andy comment, even for persistent use case, SRS will send re-=20 > invite with some CS identifier so we need to have such mechanism. [AndyH] - I assume this should be "SRS MAY send re-invite with some CS Iden= tifier..." because of course it can be the SRC that makes that decision bas= ed on policy. =20 >My > understanding from the below thread was to add the policy mentioning =20 >and not just to completely remove the mechanism mentioning. I am ok =20 >with both options. > I will remove Join example it in the next update. > [AndyH] - I think we should remove the mechanism from the architecture draf= t the "Join" example was there to promote discussion even before we had a p= rotocol draft and I think should now be removed. >=20 > Regards >=20 > Leon >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Ravindran, Parthasarathi > Sent: Monday, March 19, 2012 4:01 PM > To: Hutton, Andrew; Leon Portman > Cc: siprec@ietf.org > Subject: Re: [siprec] I-D Action:=20 > draft-ietf-siprec-architecture-04.txt >=20 > Hi Andy, >=20 > As I mentioned in the below mail, the policy of SRC should not decide=20 > what recording has to be started rather it has to be clearly mentioned=20 > by SRS and it will leads to interop issue as SRS has to expect=20 > recording based on different SRC implementation. >=20 > In case CS id is not generic enough for SRS-initiated callflow. Let us=20 > work for the list of possible standard mechanism required >=20 > 1) Communication Session-id > 2) participant > 3) stream??? >=20 > I still think that the exact SRS-initiated recording mechanism has to=20 > be mentioned in the protocol draft rather than in the architecture=20 > document. >=20 > Thanks > Partha >=20 > >-----Original Message----- > >From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > >Sent: Monday, March 19, 2012 7:20 PM > >To: Ravindran, Parthasarathi; Leon Portman > >Cc: siprec@ietf.org > >Subject: RE: [siprec] I-D Action: draft-ietf-siprec-architecture- > 04.txt > > > >Hi Leon, > > > >I expected the bullet in section 3.2.2 stating "Identify the session=20 > >that is to be recorded - Possibly using the Join header" to be=20 > >removed in this latest update. The issue was raised by Gonzalo and in=20 > >my response to those on the mailing list. (See=20 > >http://www.ietf.org/mail- archive/web/siprec/current/msg03125.html). > > > >In previous discussion I thought we had agreed at least in some=20 > >scenarios there was no need to define such a mechanism as it would be=20 > >up to policy at the SRC and for example in the persistent recording=20 > >case there may not even be a CS at the time the RS is established. > > > >Regards > >Andy > > > > > > > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > >> Behalf Of Ravindran, Parthasarathi > >> Sent: 16 March 2012 18:39 > >> To: Leon Portman > >> Cc: siprec@ietf.org > >> Subject: Re: [siprec] I-D Action: > >> draft-ietf-siprec-architecture-04.txt > >> > >> Leon, > >> > >> I agree with you. Let architecture document mentions only that the=20 > >> mechanism is required to identify the communication session in SRS-=20 > >> initiated callflow and exact mechanism will be defined in protocol=20 > >> draft. > >> > >> Thanks > >> Partha > >> > >> >-----Original Message----- > >> >From: Leon Portman [mailto:leon.portman@gmail.com] > >> >Sent: Friday, March 16, 2012 11:51 PM > >> >To: Ravindran, Parthasarathi > >> >Cc: Leon Portman; siprec@ietf.org > >> >Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture- > >> 04.txt > >> > > >> >The main question then, if it will be required to be defined in=20 > >> >the protocol draft and we can keep architecture draft at high=20 > >> >level in > >> order > >> >to move forward > >> > > >> >Leon > >> > > >> >On Mar 16, 2012, at 8:16 PM, "Ravindran, Parthasarathi" > >> > wrote: > >> > > >> >> Leon, > >> >> > >> >> I agree with you that session-id solves the reported problem. > >> >> > >> >> As you might know, Session id IETF WG namely INSIPID is in the=20 > >> >> very > >> >early stage and number of drafts under discussion for IETF-83 are > >> listed > >> >in http://www.ietf.org/mail- > >archive/web/insipid/current/msg00005.html. > >> >IMO, creating session-id dependency will delay SIPREC deliverable. > >> >We will brainstorm more to find some way without session-id if > exists. > >> >> > >> >> Thanks > >> >> Partha > >> >> > >> >>> -----Original Message----- > >> >>> From: Leon Portman [mailto:leon.portman@gmail.com] > >> >>> Sent: Friday, March 16, 2012 11:36 PM > >> >>> To: Ravindran, Parthasarathi > >> >>> Cc: Leon Portman; siprec@ietf.org > >> >>> Subject: Re: [siprec] I-D Action: > >> >>> draft-ietf-siprec-architecture-04.txt > >> >>> > >> >>> Partha, > >> >>> > >> >>> I completely agree with you. Session identification is one of > the > >> >>> main pain points today. May be Global session ID work will help > >> here? > >> >>> http://tools.ietf.org/html/draft-kaplan-dispatch-session-id-01 > >> >>> > >> >>> Leon > >> >>> > >> >>> On Mar 16, 2012, at 7:59 PM, "Ravindran, Parthasarathi" > >> >>> wrote: > >> >>> > >> >>>> Leon, > >> >>>> > >> >>>> I agree with you that it is the way proprietary SIP recording > >> works > >> >>> today. For each SRS initiated callflow, unique-id of a session > is > >> >>> generated by PBX driven or CTI, SRC is forced to develop > multiple > >> >>> solutions accordingly as there is a lack of standard mechanism. > >> >>> I have concern because SRS initiated without any specific=20 > >> >>> identification continue the same trend of today's proprietary=20 > >> >>> recording solution. I wish to see some well-defined protocol=20 > >> >>> mechanism from SRS to SRC to identity the session which has to=20 > >> >>> recorded. Please let me know your opinion. > >> >>>> > >> >>>> As you have listed number of mechanism, I'm fine in case we=20 > >> >>>> nailed > >> >>> down to one of the mechanism as standard in the worst case. > >> >>>> > >> >>>> Thanks > >> >>>> Partha > >> >>>> > >> >>>>> -----Original Message----- > >> >>>>> From: Leon Portman [mailto:leon.portman@gmail.com] > >> >>>>> Sent: Friday, March 16, 2012 11:14 PM > >> >>>>> To: Ravindran, Parthasarathi > >> >>>>> Cc: Leon Portman; siprec@ietf.org > >> >>>>> Subject: Re: [siprec] I-D Action: > >> >>>>> draft-ietf-siprec-architecture-04.txt > >> >>>>> > >> >>>>> Partha Hi > >> >>>>> > >> >>>>> The ways of identification of CS to be recorded for SRS > >> initiated > >> >>>>> flows are very dependent on actual SRC implementation. > >> >>>>> For example, if SRC is PBX, it can be even CTI call id,=20 > >> >>>>> participants ids, DNS name of end point etc. > >> >>>>> > >> >>>>> For gateways it can be IP and PORT of RTP stream for example. > >> >>>>> > >> >>>>> This what i meant that it is very defendant on SRC and on the=20 > >> >>>>> way how SRS knows about CSs. > >> >>>>> > >> >>>>> Regards > >> >>>>> > >> >>>>> Leon > >> >>>>> > >> >>>>> On Mar 14, 2012, at 4:12 PM, "Ravindran, Parthasarathi" > >> >>>>> wrote: > >> >>>>> > >> >>>>>> Leon, > >> >>>>>> > >> >>>>>> Could you please explain in detail about Sec 3.2.2 update > >> >>>>>> > >> >>>>>> " o The actual mechanism of the identification is depends > on > >> >SRC > >> >>>>>> policy." > >> >>>>>> > >> >>>>>> Thanks > >> >>>>>> partha > >> >>>>>> > >> >>>>>>> -----Original Message----- > >> >>>>>>> From: siprec-bounces@ietf.org=20 > >> >>>>>>> [mailto:siprec-bounces@ietf.org] > >> On > >> >>>>>>> Behalf Of Leon Portman > >> >>>>>>> Sent: Tuesday, March 13, 2012 9:20 PM > >> >>>>>>> To: siprec@ietf.org > >> >>>>>>> Subject: Re: [siprec] I-D Action: > >> >>>>>>> draft-ietf-siprec-architecture-04.txt > >> >>>>>>> > >> >>>>>>> Main changes. They are mainly consist from Gonzalo and=20 > >> >>>>>>> other mailing lists comments. > >> >>>>>>> > >> >>>>>>> 1. Definitions: Adding recording unaware UA definition and > >> fixing > >> >>>>>>> some other definitions 2. Consistent abbreviation usage in=20 > >> >>>>>>> the > >> >>>>> document 3. > >> >>>>>>> Figures fixes 4. Adding policy mentions in Endpoint as SRC > 5. > >> >>>>>>> Removing WEBRTC mentions 6. Adding more descriptions in SRS=20 > >> >>>>>>> initiated flows 7.Adding support for RS without metadata > >> >>>>>>> > >> >>>>>>> There are some small typo mistakes in v04. I have already=20 > >> >>>>>>> fixed them and will update in next version > >> >>>>>>> > >> >>>>>>> Regards > >> >>>>>>> > >> >>>>>>> Leon > >> >>>>>>> > >> >>>>>>> -----Original Message----- > >> >>>>>>> From: siprec-bounces@ietf.org=20 > >> >>>>>>> [mailto:siprec-bounces@ietf.org] > >> On > >> >>>>>>> Behalf Of internet-drafts@ietf.org > >> >>>>>>> Sent: Monday, March 12, 2012 3:25 PM > >> >>>>>>> To: i-d-announce@ietf.org > >> >>>>>>> Cc: siprec@ietf.org > >> >>>>>>> Subject: [siprec] I-D Action: > >> >>>>>>> draft-ietf-siprec-architecture-04.txt > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> A New Internet-Draft is available from the on-line=20 > >> >>>>>>> Internet-Drafts directories. This draft is a work item of > the > >> SIP > >> >>>>>>> Recording Working Group of the IETF. > >> >>>>>>> > >> >>>>>>> Title : An Architecture for Media Recording using > >> >the > >> >>>>>>> Session Initiation Protocol > >> >>>>>>> Author(s) : Andrew Hutton > >> >>>>>>> Leon Portman > >> >>>>>>> Rajnish Jain > >> >>>>>>> Ken Rehor > >> >>>>>>> Filename : draft-ietf-siprec-architecture-04.txt > >> >>>>>>> Pages : 16 > >> >>>>>>> Date : 2012-03-12 > >> >>>>>>> > >> >>>>>>> Session recording is a critical requirement in many=20 > >> >>>>>>> communications environments such as call centers and=20 > >> >>>>>>> financial trading. In some of these environments, all=20 > >> >>>>>>> calls must be recorded for regulatory, compliance, and=20 > >> >>>>>>> consumer protection reasons. Recording of a session is=20 > >> >>>>>>> typically performed by sending a copy of a media stream to=20 > >> >>>>>>> a recording device. This document describes architectures=20 > >> >>>>>>> for deploying session > >> recording > >> >>>>>>> solutions in an environment which is based on the Session > >> >Initiation Protocol (SIP). > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> A URL for this Internet-Draft is: > >> >>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-siprec- > >> architectur > >> >>>>>>> e- > >> >>>>>>> 04.txt > >> >>>>>>> > >> >>>>>>> Internet-Drafts are also available by anonymous FTP at: > >> >>>>>>> ftp://ftp.ietf.org/internet-drafts/ > >> >>>>>>> > >> >>>>>>> This Internet-Draft can be retrieved at: > >> >>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec- > >> architecture > >> >>>>>>> - > >> >>> 04. > >> >>>>>>> txt > >> >>>>>>> > >> >>>>>>> _______________________________________________ > >> >>>>>>> siprec mailing list > >> >>>>>>> siprec@ietf.org > >> >>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >> >>>>>>> _______________________________________________ > >> >>>>>>> siprec mailing list > >> >>>>>>> siprec@ietf.org > >> >>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >> >>>>>> _______________________________________________ > >> >>>>>> siprec mailing list > >> >>>>>> siprec@ietf.org > >> >>>>>> https://www.ietf.org/mailman/listinfo/siprec > >> >>>> > >> >> > >> > >> _______________________________________________ > >> 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 pravindran@sonusnet.com Mon Mar 19 07:26:41 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC5821F8783 for ; Mon, 19 Mar 2012 07:26:41 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7f0eczw3c5w for ; Mon, 19 Mar 2012 07:26:39 -0700 (PDT) Received: from na3sys010aog114.obsmtp.com (na3sys010aog114.obsmtp.com [74.125.245.96]) by ietfa.amsl.com (Postfix) with ESMTP id AA66821F8794 for ; Mon, 19 Mar 2012 07:26:35 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob114.postini.com ([74.125.244.12]) with SMTP ID DSNKT2dCG9CW+vXvqXovppwxJmjeXcBeOneB@postini.com; Mon, 19 Mar 2012 07:26:35 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 19 Mar 2012 10:26:48 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Mon, 19 Mar 2012 19:56:29 +0530 From: "Ravindran, Parthasarathi" To: "Hutton, Andrew" , Leon Portman , Leon Portman Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt Thread-Index: AQHNAFN+7jAuVLtiI0aefxoa4INav5ZoBQaAgAHS3hCAAwPfAIAAXQiA//+pRgCAAFzf8P//pzyAgABcY7CABGesgIAABBqQgAAEHfCAAAGZMIAAAhhw Date: Mon, 19 Mar 2012 14:26:29 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E1FFB35@inba-mail01.sonusnet.com> References: <20120312132433.19581.40959.idtracker@ietfa.amsl.com> <07465C1D981ABC41A344374066AE1A2C39DAF8C0A7@TLVMBX01.nice.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FCACA@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAD4@inba-mail01.sonusnet.com> <02E25602-BB51-4091-95E3-A5475AB4B85D@gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAF3@inba-mail01.sonusnet.com> <96F77B6A-C42F-4C45-BF24-F6BF9CCAE026@gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB37@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E31296AE1E00@MCHP058A.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C0E1FFAE6@inba-mail01.sonusnet.com> <07465C1D981ABC41A344374066AE1A2C39DAFFEC01@TLVMBX01.nice.com> <101C6067BEC68246B0C3F6843BCCC1E31296AE1E39@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31296AE1E39@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.61] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:26:41 -0000 Andy, Could you please explain how SRC policy based recording will not cause issu= e in SRS as SRS will not know what is going to be recorded when initiating = RS INVITE.=20 Based on my experience, I noticed that SRC policy based SRS-initiated callf= low cause more issue to SRC as well.=20 Thanks Partha >-----Original Message----- >From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] >Sent: Monday, March 19, 2012 7:47 PM >To: Leon Portman; Ravindran, Parthasarathi; Leon Portman >Cc: siprec@ietf.org >Subject: RE: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt > >See below. > >Regards >Andy > >> -----Original Message----- >> From: Leon Portman [mailto:Leon.Portman@nice.com] >> Sent: 19 March 2012 14:10 >> To: Ravindran, Parthasarathi; Hutton, Andrew; Leon Portman >> Cc: siprec@ietf.org >> Subject: RE: [siprec] I-D Action: >> draft-ietf-siprec-architecture-04.txt >> >> Actually these are two separate issues, one is how to identify the >> communication session, and second how to indicate it in RS invite >> (FROM SRS to SRC). >> Back to Andy comment, even for persistent use case, SRS will send re- >> invite with some CS identifier so we need to have such mechanism. > >[AndyH] - I assume this should be "SRS MAY send re-invite with some CS >Identifier..." because of course it can be the SRC that makes that >decision based on policy. > >>My >> understanding from the below thread was to add the policy mentioning >>and not just to completely remove the mechanism mentioning. I am ok >>with both options. >> I will remove Join example it in the next update. >> > >[AndyH] - I think we should remove the mechanism from the architecture >draft the "Join" example was there to promote discussion even before we >had a protocol draft and I think should now be removed. > >> >> Regards >> >> Leon >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Ravindran, Parthasarathi >> Sent: Monday, March 19, 2012 4:01 PM >> To: Hutton, Andrew; Leon Portman >> Cc: siprec@ietf.org >> Subject: Re: [siprec] I-D Action: >> draft-ietf-siprec-architecture-04.txt >> >> Hi Andy, >> >> As I mentioned in the below mail, the policy of SRC should not decide >> what recording has to be started rather it has to be clearly mentioned >> by SRS and it will leads to interop issue as SRS has to expect >> recording based on different SRC implementation. >> >> In case CS id is not generic enough for SRS-initiated callflow. Let us >> work for the list of possible standard mechanism required >> >> 1) Communication Session-id >> 2) participant >> 3) stream??? >> >> I still think that the exact SRS-initiated recording mechanism has to >> be mentioned in the protocol draft rather than in the architecture >> document. >> >> Thanks >> Partha >> >> >-----Original Message----- >> >From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] >> >Sent: Monday, March 19, 2012 7:20 PM >> >To: Ravindran, Parthasarathi; Leon Portman >> >Cc: siprec@ietf.org >> >Subject: RE: [siprec] I-D Action: draft-ietf-siprec-architecture- >> 04.txt >> > >> >Hi Leon, >> > >> >I expected the bullet in section 3.2.2 stating "Identify the session >> >that is to be recorded - Possibly using the Join header" to be >> >removed in this latest update. The issue was raised by Gonzalo and in >> >my response to those on the mailing list. (See >> >http://www.ietf.org/mail- archive/web/siprec/current/msg03125.html). >> > >> >In previous discussion I thought we had agreed at least in some >> >scenarios there was no need to define such a mechanism as it would be >> >up to policy at the SRC and for example in the persistent recording >> >case there may not even be a CS at the time the RS is established. >> > >> >Regards >> >Andy >> > >> > >> > >> > >> >> -----Original Message----- >> >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> >> Behalf Of Ravindran, Parthasarathi >> >> Sent: 16 March 2012 18:39 >> >> To: Leon Portman >> >> Cc: siprec@ietf.org >> >> Subject: Re: [siprec] I-D Action: >> >> draft-ietf-siprec-architecture-04.txt >> >> >> >> Leon, >> >> >> >> I agree with you. Let architecture document mentions only that the >> >> mechanism is required to identify the communication session in SRS- >> >> initiated callflow and exact mechanism will be defined in protocol >> >> draft. >> >> >> >> Thanks >> >> Partha >> >> >> >> >-----Original Message----- >> >> >From: Leon Portman [mailto:leon.portman@gmail.com] >> >> >Sent: Friday, March 16, 2012 11:51 PM >> >> >To: Ravindran, Parthasarathi >> >> >Cc: Leon Portman; siprec@ietf.org >> >> >Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture- >> >> 04.txt >> >> > >> >> >The main question then, if it will be required to be defined in >> >> >the protocol draft and we can keep architecture draft at high >> >> >level in >> >> order >> >> >to move forward >> >> > >> >> >Leon >> >> > >> >> >On Mar 16, 2012, at 8:16 PM, "Ravindran, Parthasarathi" >> >> > wrote: >> >> > >> >> >> Leon, >> >> >> >> >> >> I agree with you that session-id solves the reported problem. >> >> >> >> >> >> As you might know, Session id IETF WG namely INSIPID is in the >> >> >> very >> >> >early stage and number of drafts under discussion for IETF-83 are >> >> listed >> >> >in http://www.ietf.org/mail- >> >archive/web/insipid/current/msg00005.html. >> >> >IMO, creating session-id dependency will delay SIPREC deliverable. >> >> >We will brainstorm more to find some way without session-id if >> exists. >> >> >> >> >> >> Thanks >> >> >> Partha >> >> >> >> >> >>> -----Original Message----- >> >> >>> From: Leon Portman [mailto:leon.portman@gmail.com] >> >> >>> Sent: Friday, March 16, 2012 11:36 PM >> >> >>> To: Ravindran, Parthasarathi >> >> >>> Cc: Leon Portman; siprec@ietf.org >> >> >>> Subject: Re: [siprec] I-D Action: >> >> >>> draft-ietf-siprec-architecture-04.txt >> >> >>> >> >> >>> Partha, >> >> >>> >> >> >>> I completely agree with you. Session identification is one of >> the >> >> >>> main pain points today. May be Global session ID work will help >> >> here? >> >> >>> http://tools.ietf.org/html/draft-kaplan-dispatch-session-id-01 >> >> >>> >> >> >>> Leon >> >> >>> >> >> >>> On Mar 16, 2012, at 7:59 PM, "Ravindran, Parthasarathi" >> >> >>> wrote: >> >> >>> >> >> >>>> Leon, >> >> >>>> >> >> >>>> I agree with you that it is the way proprietary SIP recording >> >> works >> >> >>> today. For each SRS initiated callflow, unique-id of a session >> is >> >> >>> generated by PBX driven or CTI, SRC is forced to develop >> multiple >> >> >>> solutions accordingly as there is a lack of standard mechanism. >> >> >>> I have concern because SRS initiated without any specific >> >> >>> identification continue the same trend of today's proprietary >> >> >>> recording solution. I wish to see some well-defined protocol >> >> >>> mechanism from SRS to SRC to identity the session which has to >> >> >>> recorded. Please let me know your opinion. >> >> >>>> >> >> >>>> As you have listed number of mechanism, I'm fine in case we >> >> >>>> nailed >> >> >>> down to one of the mechanism as standard in the worst case. >> >> >>>> >> >> >>>> Thanks >> >> >>>> Partha >> >> >>>> >> >> >>>>> -----Original Message----- >> >> >>>>> From: Leon Portman [mailto:leon.portman@gmail.com] >> >> >>>>> Sent: Friday, March 16, 2012 11:14 PM >> >> >>>>> To: Ravindran, Parthasarathi >> >> >>>>> Cc: Leon Portman; siprec@ietf.org >> >> >>>>> Subject: Re: [siprec] I-D Action: >> >> >>>>> draft-ietf-siprec-architecture-04.txt >> >> >>>>> >> >> >>>>> Partha Hi >> >> >>>>> >> >> >>>>> The ways of identification of CS to be recorded for SRS >> >> initiated >> >> >>>>> flows are very dependent on actual SRC implementation. >> >> >>>>> For example, if SRC is PBX, it can be even CTI call id, >> >> >>>>> participants ids, DNS name of end point etc. >> >> >>>>> >> >> >>>>> For gateways it can be IP and PORT of RTP stream for example. >> >> >>>>> >> >> >>>>> This what i meant that it is very defendant on SRC and on the >> >> >>>>> way how SRS knows about CSs. >> >> >>>>> >> >> >>>>> Regards >> >> >>>>> >> >> >>>>> Leon >> >> >>>>> >> >> >>>>> On Mar 14, 2012, at 4:12 PM, "Ravindran, Parthasarathi" >> >> >>>>> wrote: >> >> >>>>> >> >> >>>>>> Leon, >> >> >>>>>> >> >> >>>>>> Could you please explain in detail about Sec 3.2.2 update >> >> >>>>>> >> >> >>>>>> " o The actual mechanism of the identification is depends >> on >> >> >SRC >> >> >>>>>> policy." >> >> >>>>>> >> >> >>>>>> Thanks >> >> >>>>>> partha >> >> >>>>>> >> >> >>>>>>> -----Original Message----- >> >> >>>>>>> From: siprec-bounces@ietf.org >> >> >>>>>>> [mailto:siprec-bounces@ietf.org] >> >> On >> >> >>>>>>> Behalf Of Leon Portman >> >> >>>>>>> Sent: Tuesday, March 13, 2012 9:20 PM >> >> >>>>>>> To: siprec@ietf.org >> >> >>>>>>> Subject: Re: [siprec] I-D Action: >> >> >>>>>>> draft-ietf-siprec-architecture-04.txt >> >> >>>>>>> >> >> >>>>>>> Main changes. They are mainly consist from Gonzalo and >> >> >>>>>>> other mailing lists comments. >> >> >>>>>>> >> >> >>>>>>> 1. Definitions: Adding recording unaware UA definition and >> >> fixing >> >> >>>>>>> some other definitions 2. Consistent abbreviation usage in >> >> >>>>>>> the >> >> >>>>> document 3. >> >> >>>>>>> Figures fixes 4. Adding policy mentions in Endpoint as SRC >> 5. >> >> >>>>>>> Removing WEBRTC mentions 6. Adding more descriptions in SRS >> >> >>>>>>> initiated flows 7.Adding support for RS without metadata >> >> >>>>>>> >> >> >>>>>>> There are some small typo mistakes in v04. I have already >> >> >>>>>>> fixed them and will update in next version >> >> >>>>>>> >> >> >>>>>>> Regards >> >> >>>>>>> >> >> >>>>>>> Leon >> >> >>>>>>> >> >> >>>>>>> -----Original Message----- >> >> >>>>>>> From: siprec-bounces@ietf.org >> >> >>>>>>> [mailto:siprec-bounces@ietf.org] >> >> On >> >> >>>>>>> Behalf Of internet-drafts@ietf.org >> >> >>>>>>> Sent: Monday, March 12, 2012 3:25 PM >> >> >>>>>>> To: i-d-announce@ietf.org >> >> >>>>>>> Cc: siprec@ietf.org >> >> >>>>>>> Subject: [siprec] I-D Action: >> >> >>>>>>> draft-ietf-siprec-architecture-04.txt >> >> >>>>>>> >> >> >>>>>>> >> >> >>>>>>> A New Internet-Draft is available from the on-line >> >> >>>>>>> Internet-Drafts directories. This draft is a work item of >> the >> >> SIP >> >> >>>>>>> Recording Working Group of the IETF. >> >> >>>>>>> >> >> >>>>>>> Title : An Architecture for Media Recording >using >> >> >the >> >> >>>>>>> Session Initiation Protocol >> >> >>>>>>> Author(s) : Andrew Hutton >> >> >>>>>>> Leon Portman >> >> >>>>>>> Rajnish Jain >> >> >>>>>>> Ken Rehor >> >> >>>>>>> Filename : draft-ietf-siprec-architecture- >04.txt >> >> >>>>>>> Pages : 16 >> >> >>>>>>> Date : 2012-03-12 >> >> >>>>>>> >> >> >>>>>>> Session recording is a critical requirement in many >> >> >>>>>>> communications environments such as call centers and >> >> >>>>>>> financial trading. In some of these environments, all >> >> >>>>>>> calls must be recorded for regulatory, compliance, and >> >> >>>>>>> consumer protection reasons. Recording of a session is >> >> >>>>>>> typically performed by sending a copy of a media stream to >> >> >>>>>>> a recording device. This document describes architectures >> >> >>>>>>> for deploying session >> >> recording >> >> >>>>>>> solutions in an environment which is based on the Session >> >> >Initiation Protocol (SIP). >> >> >>>>>>> >> >> >>>>>>> >> >> >>>>>>> A URL for this Internet-Draft is: >> >> >>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-siprec- >> >> architectur >> >> >>>>>>> e- >> >> >>>>>>> 04.txt >> >> >>>>>>> >> >> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >> >> >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >> >> >>>>>>> >> >> >>>>>>> This Internet-Draft can be retrieved at: >> >> >>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec- >> >> architecture >> >> >>>>>>> - >> >> >>> 04. >> >> >>>>>>> txt >> >> >>>>>>> >> >> >>>>>>> _______________________________________________ >> >> >>>>>>> siprec mailing list >> >> >>>>>>> siprec@ietf.org >> >> >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >> >> >>>>>>> _______________________________________________ >> >> >>>>>>> siprec mailing list >> >> >>>>>>> siprec@ietf.org >> >> >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >> >> >>>>>> _______________________________________________ >> >> >>>>>> siprec mailing list >> >> >>>>>> siprec@ietf.org >> >> >>>>>> https://www.ietf.org/mailman/listinfo/siprec >> >> >>>> >> >> >> >> >> >> >> _______________________________________________ >> >> 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 trac+siprec@trac.tools.ietf.org Mon Mar 19 07:32:03 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDA721F87DB for ; Mon, 19 Mar 2012 07:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shUjp1uNu4uG for ; Mon, 19 Mar 2012 07:32:02 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id B239621F87D8 for ; Mon, 19 Mar 2012 07:32:02 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S9dct-0003A8-2T; Mon, 19 Mar 2012 10:31:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "siprec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: leonp@nice.com X-Trac-Project: siprec Date: Mon, 19 Mar 2012 14:31:58 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/81#comment:2 Message-ID: <070.d057f3bacf44abfc4893eedbb7b8b38f@trac.tools.ietf.org> References: <055.c00650f99af099fadb89d26ad7661f06@trac.tools.ietf.org> X-Trac-Ticket-ID: 81 In-Reply-To: <055.c00650f99af099fadb89d26ad7661f06@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: leonp@nice.com, siprec@ietf.org X-SA-Exim-Mail-From: trac+siprec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: siprec@ietf.org Subject: Re: [siprec] #81: CS identification in SRS initiated recording X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:32:03 -0000 #81: CS identification in SRS initiated recording Comment (by leonp@…): need to update next version according to following discussion: http://www.ietf.org/mail-archive/web/siprec/current/msg03193.html -- --------------------------+---------------------- Reporter: leonp@… | Owner: leonp@… Type: defect | Status: new Priority: major | Milestone: Component: Architecture | Version: Severity: - | Resolution: Keywords: | --------------------------+---------------------- Ticket URL: siprec From andrew.hutton@siemens-enterprise.com Mon Mar 19 07:35:09 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E1E21F87E7 for ; Mon, 19 Mar 2012 07:35:09 -0700 (PDT) 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.098, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hSyY8J7-OvI for ; Mon, 19 Mar 2012 07:35:09 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 4625321F87E0 for ; Mon, 19 Mar 2012 07:35:09 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 7761923F0496 for ; Mon, 19 Mar 2012 15:35:08 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 19 Mar 2012 15:35:08 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Date: Mon, 19 Mar 2012 15:35:07 +0100 Thread-Topic: RTCWeb DTLS-SRTP , SDES, RTP etc. Thread-Index: Ac0F3Xrq8q1zTRBYSIWJMv/wBq1wjA== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31296AE1E6D@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] RTCWeb DTLS-SRTP , SDES, RTP etc. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 19 Mar 2012 14:35:10 -0000 Hi All, The RTCWeb working group are hoping to make a decision on the use of DTLS-S= RTP, SDES-SRTP and plain RTP at IETF83. This could well go in the direction= that RTCWeb clients only support DTLS-SRTP or at very least that DTLS-SRTP= is the preferred choice. I am interested in opinions as to whether we need to do more work in unders= tand the implication of recording communication session that use DTLS-SRTP = and if so where we should do this. Probably http://tools.ietf.org/html/draft-eckel-siprec-rtp-rec-03 is the pl= ace to do this if we need to. Any comments? Regards Andy From pkyzivat@alum.mit.edu Mon Mar 19 07:39:21 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A2421F86F6 for ; Mon, 19 Mar 2012 07:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fq675idiYlEl for ; Mon, 19 Mar 2012 07:39:19 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id DD57D21F84D7 for ; Mon, 19 Mar 2012 07:39:14 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta13.westchester.pa.mail.comcast.net with comcast id nRr31i0011YDfWL5DSfFCl; Mon, 19 Mar 2012 14:39:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta20.westchester.pa.mail.comcast.net with comcast id nSfF1i00C07duvL3gSfFJs; Mon, 19 Mar 2012 14:39:15 +0000 Message-ID: <4F674510.6040605@alum.mit.edu> Date: Mon, 19 Mar 2012 10:39:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <20120312132433.19581.40959.idtracker@ietfa.amsl.com> <07465C1D981ABC41A344374066AE1A2C39DAF8C0A7@TLVMBX01.nice.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FCACA@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAD4@inba-mail01.sonusnet.com> <02E25602-BB51-4091-95E3-A5475AB4B85D@gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAF3@inba-mail01.sonusnet.com> <96F77B6A-C42F-4C45-BF24-F6BF9CCAE026@gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB37@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E31296AE1E00@MCHP058A.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C0E1FFAE6@inba-mail01.sonusnet.com> <07465C1D981ABC41A344374066AE1A2C39DAFFEC01@TLVMBX01.nice.com> <101C6067BEC68246B0C3F6843BCCC1E31296AE1E39@MCHP058A.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C0E1FFB35@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E1FFB35@inba-mail01.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:39:21 -0000 On 3/19/12 10:26 AM, Ravindran, Parthasarathi wrote: > Andy, > > Could you please explain how SRC policy based recording will not cause issue in SRS as SRS will not know what is going to be recorded when initiating RS INVITE. > > Based on my experience, I noticed that SRC policy based SRS-initiated callflow cause more issue to SRC as well. It is my understanding that selection of what is to be recorded in an SRS initiated RS is *out of scope*. We allow the SRS to initiate an RS but don't say anything about how the SRC then decides what to record. Practically speaking that makes it SRC policy. If the SRS chooses to use some private extension to indicate the recording target(s) then that is effectively still an SRC policy, since the SRC must choose to honor the extension. The alternative is to put this in scope and define some specific mechanism(s) for the SRS to indicate the target(s) to the SRC. If we go that way it seems to require added normative behavior on the SRC. Thanks, Paul > Thanks > Partha > >> -----Original Message----- >> From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] >> Sent: Monday, March 19, 2012 7:47 PM >> To: Leon Portman; Ravindran, Parthasarathi; Leon Portman >> Cc: siprec@ietf.org >> Subject: RE: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt >> >> See below. >> >> Regards >> Andy >> >>> -----Original Message----- >>> From: Leon Portman [mailto:Leon.Portman@nice.com] >>> Sent: 19 March 2012 14:10 >>> To: Ravindran, Parthasarathi; Hutton, Andrew; Leon Portman >>> Cc: siprec@ietf.org >>> Subject: RE: [siprec] I-D Action: >>> draft-ietf-siprec-architecture-04.txt >>> >>> Actually these are two separate issues, one is how to identify the >>> communication session, and second how to indicate it in RS invite >>> (FROM SRS to SRC). >>> Back to Andy comment, even for persistent use case, SRS will send re- >>> invite with some CS identifier so we need to have such mechanism. >> >> [AndyH] - I assume this should be "SRS MAY send re-invite with some CS >> Identifier..." because of course it can be the SRC that makes that >> decision based on policy. >> >>> My >>> understanding from the below thread was to add the policy mentioning >>> and not just to completely remove the mechanism mentioning. I am ok >>> with both options. >>> I will remove Join example it in the next update. >>> >> >> [AndyH] - I think we should remove the mechanism from the architecture >> draft the "Join" example was there to promote discussion even before we >> had a protocol draft and I think should now be removed. >> >>> >>> Regards >>> >>> Leon >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Ravindran, Parthasarathi >>> Sent: Monday, March 19, 2012 4:01 PM >>> To: Hutton, Andrew; Leon Portman >>> Cc: siprec@ietf.org >>> Subject: Re: [siprec] I-D Action: >>> draft-ietf-siprec-architecture-04.txt >>> >>> Hi Andy, >>> >>> As I mentioned in the below mail, the policy of SRC should not decide >>> what recording has to be started rather it has to be clearly mentioned >>> by SRS and it will leads to interop issue as SRS has to expect >>> recording based on different SRC implementation. >>> >>> In case CS id is not generic enough for SRS-initiated callflow. Let us >>> work for the list of possible standard mechanism required >>> >>> 1) Communication Session-id >>> 2) participant >>> 3) stream??? >>> >>> I still think that the exact SRS-initiated recording mechanism has to >>> be mentioned in the protocol draft rather than in the architecture >>> document. >>> >>> Thanks >>> Partha >>> >>>> -----Original Message----- >>>> From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] >>>> Sent: Monday, March 19, 2012 7:20 PM >>>> To: Ravindran, Parthasarathi; Leon Portman >>>> Cc: siprec@ietf.org >>>> Subject: RE: [siprec] I-D Action: draft-ietf-siprec-architecture- >>> 04.txt >>>> >>>> Hi Leon, >>>> >>>> I expected the bullet in section 3.2.2 stating "Identify the session >>>> that is to be recorded - Possibly using the Join header" to be >>>> removed in this latest update. The issue was raised by Gonzalo and in >>>> my response to those on the mailing list. (See >>>> http://www.ietf.org/mail- archive/web/siprec/current/msg03125.html). >>>> >>>> In previous discussion I thought we had agreed at least in some >>>> scenarios there was no need to define such a mechanism as it would be >>>> up to policy at the SRC and for example in the persistent recording >>>> case there may not even be a CS at the time the RS is established. >>>> >>>> Regards >>>> Andy >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>> Behalf Of Ravindran, Parthasarathi >>>>> Sent: 16 March 2012 18:39 >>>>> To: Leon Portman >>>>> Cc: siprec@ietf.org >>>>> Subject: Re: [siprec] I-D Action: >>>>> draft-ietf-siprec-architecture-04.txt >>>>> >>>>> Leon, >>>>> >>>>> I agree with you. Let architecture document mentions only that the >>>>> mechanism is required to identify the communication session in SRS- >>>>> initiated callflow and exact mechanism will be defined in protocol >>>>> draft. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>>> -----Original Message----- >>>>>> From: Leon Portman [mailto:leon.portman@gmail.com] >>>>>> Sent: Friday, March 16, 2012 11:51 PM >>>>>> To: Ravindran, Parthasarathi >>>>>> Cc: Leon Portman; siprec@ietf.org >>>>>> Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture- >>>>> 04.txt >>>>>> >>>>>> The main question then, if it will be required to be defined in >>>>>> the protocol draft and we can keep architecture draft at high >>>>>> level in >>>>> order >>>>>> to move forward >>>>>> >>>>>> Leon >>>>>> >>>>>> On Mar 16, 2012, at 8:16 PM, "Ravindran, Parthasarathi" >>>>>> wrote: >>>>>> >>>>>>> Leon, >>>>>>> >>>>>>> I agree with you that session-id solves the reported problem. >>>>>>> >>>>>>> As you might know, Session id IETF WG namely INSIPID is in the >>>>>>> very >>>>>> early stage and number of drafts under discussion for IETF-83 are >>>>> listed >>>>>> in http://www.ietf.org/mail- >>>> archive/web/insipid/current/msg00005.html. >>>>>> IMO, creating session-id dependency will delay SIPREC deliverable. >>>>>> We will brainstorm more to find some way without session-id if >>> exists. >>>>>>> >>>>>>> Thanks >>>>>>> Partha >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Leon Portman [mailto:leon.portman@gmail.com] >>>>>>>> Sent: Friday, March 16, 2012 11:36 PM >>>>>>>> To: Ravindran, Parthasarathi >>>>>>>> Cc: Leon Portman; siprec@ietf.org >>>>>>>> Subject: Re: [siprec] I-D Action: >>>>>>>> draft-ietf-siprec-architecture-04.txt >>>>>>>> >>>>>>>> Partha, >>>>>>>> >>>>>>>> I completely agree with you. Session identification is one of >>> the >>>>>>>> main pain points today. May be Global session ID work will help >>>>> here? >>>>>>>> http://tools.ietf.org/html/draft-kaplan-dispatch-session-id-01 >>>>>>>> >>>>>>>> Leon >>>>>>>> >>>>>>>> On Mar 16, 2012, at 7:59 PM, "Ravindran, Parthasarathi" >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Leon, >>>>>>>>> >>>>>>>>> I agree with you that it is the way proprietary SIP recording >>>>> works >>>>>>>> today. For each SRS initiated callflow, unique-id of a session >>> is >>>>>>>> generated by PBX driven or CTI, SRC is forced to develop >>> multiple >>>>>>>> solutions accordingly as there is a lack of standard mechanism. >>>>>>>> I have concern because SRS initiated without any specific >>>>>>>> identification continue the same trend of today's proprietary >>>>>>>> recording solution. I wish to see some well-defined protocol >>>>>>>> mechanism from SRS to SRC to identity the session which has to >>>>>>>> recorded. Please let me know your opinion. >>>>>>>>> >>>>>>>>> As you have listed number of mechanism, I'm fine in case we >>>>>>>>> nailed >>>>>>>> down to one of the mechanism as standard in the worst case. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Partha >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Leon Portman [mailto:leon.portman@gmail.com] >>>>>>>>>> Sent: Friday, March 16, 2012 11:14 PM >>>>>>>>>> To: Ravindran, Parthasarathi >>>>>>>>>> Cc: Leon Portman; siprec@ietf.org >>>>>>>>>> Subject: Re: [siprec] I-D Action: >>>>>>>>>> draft-ietf-siprec-architecture-04.txt >>>>>>>>>> >>>>>>>>>> Partha Hi >>>>>>>>>> >>>>>>>>>> The ways of identification of CS to be recorded for SRS >>>>> initiated >>>>>>>>>> flows are very dependent on actual SRC implementation. >>>>>>>>>> For example, if SRC is PBX, it can be even CTI call id, >>>>>>>>>> participants ids, DNS name of end point etc. >>>>>>>>>> >>>>>>>>>> For gateways it can be IP and PORT of RTP stream for example. >>>>>>>>>> >>>>>>>>>> This what i meant that it is very defendant on SRC and on the >>>>>>>>>> way how SRS knows about CSs. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> >>>>>>>>>> Leon >>>>>>>>>> >>>>>>>>>> On Mar 14, 2012, at 4:12 PM, "Ravindran, Parthasarathi" >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Leon, >>>>>>>>>>> >>>>>>>>>>> Could you please explain in detail about Sec 3.2.2 update >>>>>>>>>>> >>>>>>>>>>> " o The actual mechanism of the identification is depends >>> on >>>>>> SRC >>>>>>>>>>> policy." >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> partha >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: siprec-bounces@ietf.org >>>>>>>>>>>> [mailto:siprec-bounces@ietf.org] >>>>> On >>>>>>>>>>>> Behalf Of Leon Portman >>>>>>>>>>>> Sent: Tuesday, March 13, 2012 9:20 PM >>>>>>>>>>>> To: siprec@ietf.org >>>>>>>>>>>> Subject: Re: [siprec] I-D Action: >>>>>>>>>>>> draft-ietf-siprec-architecture-04.txt >>>>>>>>>>>> >>>>>>>>>>>> Main changes. They are mainly consist from Gonzalo and >>>>>>>>>>>> other mailing lists comments. >>>>>>>>>>>> >>>>>>>>>>>> 1. Definitions: Adding recording unaware UA definition and >>>>> fixing >>>>>>>>>>>> some other definitions 2. Consistent abbreviation usage in >>>>>>>>>>>> the >>>>>>>>>> document 3. >>>>>>>>>>>> Figures fixes 4. Adding policy mentions in Endpoint as SRC >>> 5. >>>>>>>>>>>> Removing WEBRTC mentions 6. Adding more descriptions in SRS >>>>>>>>>>>> initiated flows 7.Adding support for RS without metadata >>>>>>>>>>>> >>>>>>>>>>>> There are some small typo mistakes in v04. I have already >>>>>>>>>>>> fixed them and will update in next version >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> >>>>>>>>>>>> Leon >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: siprec-bounces@ietf.org >>>>>>>>>>>> [mailto:siprec-bounces@ietf.org] >>>>> On >>>>>>>>>>>> Behalf Of internet-drafts@ietf.org >>>>>>>>>>>> Sent: Monday, March 12, 2012 3:25 PM >>>>>>>>>>>> To: i-d-announce@ietf.org >>>>>>>>>>>> Cc: siprec@ietf.org >>>>>>>>>>>> Subject: [siprec] I-D Action: >>>>>>>>>>>> draft-ietf-siprec-architecture-04.txt >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> A New Internet-Draft is available from the on-line >>>>>>>>>>>> Internet-Drafts directories. This draft is a work item of >>> the >>>>> SIP >>>>>>>>>>>> Recording Working Group of the IETF. >>>>>>>>>>>> >>>>>>>>>>>> Title : An Architecture for Media Recording >> using >>>>>> the >>>>>>>>>>>> Session Initiation Protocol >>>>>>>>>>>> Author(s) : Andrew Hutton >>>>>>>>>>>> Leon Portman >>>>>>>>>>>> Rajnish Jain >>>>>>>>>>>> Ken Rehor >>>>>>>>>>>> Filename : draft-ietf-siprec-architecture- >> 04.txt >>>>>>>>>>>> Pages : 16 >>>>>>>>>>>> Date : 2012-03-12 >>>>>>>>>>>> >>>>>>>>>>>> Session recording is a critical requirement in many >>>>>>>>>>>> communications environments such as call centers and >>>>>>>>>>>> financial trading. In some of these environments, all >>>>>>>>>>>> calls must be recorded for regulatory, compliance, and >>>>>>>>>>>> consumer protection reasons. Recording of a session is >>>>>>>>>>>> typically performed by sending a copy of a media stream to >>>>>>>>>>>> a recording device. This document describes architectures >>>>>>>>>>>> for deploying session >>>>> recording >>>>>>>>>>>> solutions in an environment which is based on the Session >>>>>> Initiation Protocol (SIP). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> A URL for this Internet-Draft is: >>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-siprec- >>>>> architectur >>>>>>>>>>>> e- >>>>>>>>>>>> 04.txt >>>>>>>>>>>> >>>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>>> >>>>>>>>>>>> This Internet-Draft can be retrieved at: >>>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec- >>>>> architecture >>>>>>>>>>>> - >>>>>>>> 04. >>>>>>>>>>>> txt >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> siprec mailing list >>>>>>>>>>>> siprec@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> siprec mailing list >>>>>>>>>>>> siprec@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> siprec mailing list >>>>>>>>>>> siprec@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>> >>>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 Mar 19 07:46:50 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8B821F85F8 for ; Mon, 19 Mar 2012 07:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgOvjXm1kN4P for ; Mon, 19 Mar 2012 07:46:48 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 17F1021F86A3 for ; Mon, 19 Mar 2012 07:46:48 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 77BF723F0436; Mon, 19 Mar 2012 15:46:47 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 19 Mar 2012 15:46:47 +0100 From: "Hutton, Andrew" To: "Ravindran, Parthasarathi" , Leon Portman , Leon Portman Date: Mon, 19 Mar 2012 15:46:46 +0100 Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt Thread-Index: AQHNAFN+7jAuVLtiI0aefxoa4INav5ZoBQaAgAHS3hCAAwPfAIAAXQiA//+pRgCAAFzf8P//pzyAgABcY7CABGesgIAABBqQgAAEHfCAAAGZMIAAAhhwgAAFcOA= Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31296AE1E8B@MCHP058A.global-ad.net> References: <20120312132433.19581.40959.idtracker@ietfa.amsl.com> <07465C1D981ABC41A344374066AE1A2C39DAF8C0A7@TLVMBX01.nice.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FCACA@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAD4@inba-mail01.sonusnet.com> <02E25602-BB51-4091-95E3-A5475AB4B85D@gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEAF3@inba-mail01.sonusnet.com> <96F77B6A-C42F-4C45-BF24-F6BF9CCAE026@gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB37@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E31296AE1E00@MCHP058A.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C0E1FFAE6@inba-mail01.sonusnet.com> <07465C1D981ABC41A344374066AE1A2C39DAFFEC01@TLVMBX01.nice.com> <101C6067BEC68246B0C3F6843BCCC1E31296AE1E39@MCHP058A.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C0E1FFB35@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E1FFB35@inba-mail01.sonusnet.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] I-D Action: draft-ietf-siprec-architecture-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:46:50 -0000 Hi Partha, I am not sure I understand your concern. The minimum an SRS may know is tha= t it needs to initiate a RS with certain SRC's but it does not necessarily = need to know exactly what is going to be recorded. The SRC will tell the SR= S what is being recorded using SDP and metadata. Regards Andy > -----Original Message----- > From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > Sent: 19 March 2012 14:26 > To: Hutton, Andrew; Leon Portman; Leon Portman > Cc: siprec@ietf.org > Subject: RE: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt > > Andy, > > Could you please explain how SRC policy based recording will not cause > issue in SRS as SRS will not know what is going to be recorded when > initiating RS INVITE. > > Based on my experience, I noticed that SRC policy based SRS-initiated > callflow cause more issue to SRC as well. > > Thanks > Partha > > >-----Original Message----- > >From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > >Sent: Monday, March 19, 2012 7:47 PM > >To: Leon Portman; Ravindran, Parthasarathi; Leon Portman > >Cc: siprec@ietf.org > >Subject: RE: [siprec] I-D Action: draft-ietf-siprec-architecture- > 04.txt > > > >See below. > > > >Regards > >Andy > > > >> -----Original Message----- > >> From: Leon Portman [mailto:Leon.Portman@nice.com] > >> Sent: 19 March 2012 14:10 > >> To: Ravindran, Parthasarathi; Hutton, Andrew; Leon Portman > >> Cc: siprec@ietf.org > >> Subject: RE: [siprec] I-D Action: > >> draft-ietf-siprec-architecture-04.txt > >> > >> Actually these are two separate issues, one is how to identify the > >> communication session, and second how to indicate it in RS invite > >> (FROM SRS to SRC). > >> Back to Andy comment, even for persistent use case, SRS will send > re- > >> invite with some CS identifier so we need to have such mechanism. > > > >[AndyH] - I assume this should be "SRS MAY send re-invite with some CS > >Identifier..." because of course it can be the SRC that makes that > >decision based on policy. > > > >>My > >> understanding from the below thread was to add the policy mentioning > >>and not just to completely remove the mechanism mentioning. I am ok > >>with both options. > >> I will remove Join example it in the next update. > >> > > > >[AndyH] - I think we should remove the mechanism from the architecture > >draft the "Join" example was there to promote discussion even before > we > >had a protocol draft and I think should now be removed. > > > >> > >> Regards > >> > >> Leon > >> > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Ravindran, Parthasarathi > >> Sent: Monday, March 19, 2012 4:01 PM > >> To: Hutton, Andrew; Leon Portman > >> Cc: siprec@ietf.org > >> Subject: Re: [siprec] I-D Action: > >> draft-ietf-siprec-architecture-04.txt > >> > >> Hi Andy, > >> > >> As I mentioned in the below mail, the policy of SRC should not > decide > >> what recording has to be started rather it has to be clearly > mentioned > >> by SRS and it will leads to interop issue as SRS has to expect > >> recording based on different SRC implementation. > >> > >> In case CS id is not generic enough for SRS-initiated callflow. Let > us > >> work for the list of possible standard mechanism required > >> > >> 1) Communication Session-id > >> 2) participant > >> 3) stream??? > >> > >> I still think that the exact SRS-initiated recording mechanism has > to > >> be mentioned in the protocol draft rather than in the architecture > >> document. > >> > >> Thanks > >> Partha > >> > >> >-----Original Message----- > >> >From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > >> >Sent: Monday, March 19, 2012 7:20 PM > >> >To: Ravindran, Parthasarathi; Leon Portman > >> >Cc: siprec@ietf.org > >> >Subject: RE: [siprec] I-D Action: draft-ietf-siprec-architecture- > >> 04.txt > >> > > >> >Hi Leon, > >> > > >> >I expected the bullet in section 3.2.2 stating "Identify the > session > >> >that is to be recorded - Possibly using the Join header" to be > >> >removed in this latest update. The issue was raised by Gonzalo and > in > >> >my response to those on the mailing list. (See > >> >http://www.ietf.org/mail- > archive/web/siprec/current/msg03125.html). > >> > > >> >In previous discussion I thought we had agreed at least in some > >> >scenarios there was no need to define such a mechanism as it would > be > >> >up to policy at the SRC and for example in the persistent recording > >> >case there may not even be a CS at the time the RS is established. > >> > > >> >Regards > >> >Andy > >> > > >> > > >> > > >> > > >> >> -----Original Message----- > >> >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> >> Behalf Of Ravindran, Parthasarathi > >> >> Sent: 16 March 2012 18:39 > >> >> To: Leon Portman > >> >> Cc: siprec@ietf.org > >> >> Subject: Re: [siprec] I-D Action: > >> >> draft-ietf-siprec-architecture-04.txt > >> >> > >> >> Leon, > >> >> > >> >> I agree with you. Let architecture document mentions only that > the > >> >> mechanism is required to identify the communication session in > SRS- > >> >> initiated callflow and exact mechanism will be defined in > protocol > >> >> draft. > >> >> > >> >> Thanks > >> >> Partha > >> >> > >> >> >-----Original Message----- > >> >> >From: Leon Portman [mailto:leon.portman@gmail.com] > >> >> >Sent: Friday, March 16, 2012 11:51 PM > >> >> >To: Ravindran, Parthasarathi > >> >> >Cc: Leon Portman; siprec@ietf.org > >> >> >Subject: Re: [siprec] I-D Action: draft-ietf-siprec- > architecture- > >> >> 04.txt > >> >> > > >> >> >The main question then, if it will be required to be defined in > >> >> >the protocol draft and we can keep architecture draft at high > >> >> >level in > >> >> order > >> >> >to move forward > >> >> > > >> >> >Leon > >> >> > > >> >> >On Mar 16, 2012, at 8:16 PM, "Ravindran, Parthasarathi" > >> >> > wrote: > >> >> > > >> >> >> Leon, > >> >> >> > >> >> >> I agree with you that session-id solves the reported problem. > >> >> >> > >> >> >> As you might know, Session id IETF WG namely INSIPID is in the > >> >> >> very > >> >> >early stage and number of drafts under discussion for IETF-83 > are > >> >> listed > >> >> >in http://www.ietf.org/mail- > >> >archive/web/insipid/current/msg00005.html. > >> >> >IMO, creating session-id dependency will delay SIPREC > deliverable. > >> >> >We will brainstorm more to find some way without session-id if > >> exists. > >> >> >> > >> >> >> Thanks > >> >> >> Partha > >> >> >> > >> >> >>> -----Original Message----- > >> >> >>> From: Leon Portman [mailto:leon.portman@gmail.com] > >> >> >>> Sent: Friday, March 16, 2012 11:36 PM > >> >> >>> To: Ravindran, Parthasarathi > >> >> >>> Cc: Leon Portman; siprec@ietf.org > >> >> >>> Subject: Re: [siprec] I-D Action: > >> >> >>> draft-ietf-siprec-architecture-04.txt > >> >> >>> > >> >> >>> Partha, > >> >> >>> > >> >> >>> I completely agree with you. Session identification is one of > >> the > >> >> >>> main pain points today. May be Global session ID work will > help > >> >> here? > >> >> >>> http://tools.ietf.org/html/draft-kaplan-dispatch-session-id- > 01 > >> >> >>> > >> >> >>> Leon > >> >> >>> > >> >> >>> On Mar 16, 2012, at 7:59 PM, "Ravindran, Parthasarathi" > >> >> >>> wrote: > >> >> >>> > >> >> >>>> Leon, > >> >> >>>> > >> >> >>>> I agree with you that it is the way proprietary SIP > recording > >> >> works > >> >> >>> today. For each SRS initiated callflow, unique-id of a > session > >> is > >> >> >>> generated by PBX driven or CTI, SRC is forced to develop > >> multiple > >> >> >>> solutions accordingly as there is a lack of standard > mechanism. > >> >> >>> I have concern because SRS initiated without any specific > >> >> >>> identification continue the same trend of today's proprietary > >> >> >>> recording solution. I wish to see some well-defined protocol > >> >> >>> mechanism from SRS to SRC to identity the session which has > to > >> >> >>> recorded. Please let me know your opinion. > >> >> >>>> > >> >> >>>> As you have listed number of mechanism, I'm fine in case we > >> >> >>>> nailed > >> >> >>> down to one of the mechanism as standard in the worst case. > >> >> >>>> > >> >> >>>> Thanks > >> >> >>>> Partha > >> >> >>>> > >> >> >>>>> -----Original Message----- > >> >> >>>>> From: Leon Portman [mailto:leon.portman@gmail.com] > >> >> >>>>> Sent: Friday, March 16, 2012 11:14 PM > >> >> >>>>> To: Ravindran, Parthasarathi > >> >> >>>>> Cc: Leon Portman; siprec@ietf.org > >> >> >>>>> Subject: Re: [siprec] I-D Action: > >> >> >>>>> draft-ietf-siprec-architecture-04.txt > >> >> >>>>> > >> >> >>>>> Partha Hi > >> >> >>>>> > >> >> >>>>> The ways of identification of CS to be recorded for SRS > >> >> initiated > >> >> >>>>> flows are very dependent on actual SRC implementation. > >> >> >>>>> For example, if SRC is PBX, it can be even CTI call id, > >> >> >>>>> participants ids, DNS name of end point etc. > >> >> >>>>> > >> >> >>>>> For gateways it can be IP and PORT of RTP stream for > example. > >> >> >>>>> > >> >> >>>>> This what i meant that it is very defendant on SRC and on > the > >> >> >>>>> way how SRS knows about CSs. > >> >> >>>>> > >> >> >>>>> Regards > >> >> >>>>> > >> >> >>>>> Leon > >> >> >>>>> > >> >> >>>>> On Mar 14, 2012, at 4:12 PM, "Ravindran, Parthasarathi" > >> >> >>>>> wrote: > >> >> >>>>> > >> >> >>>>>> Leon, > >> >> >>>>>> > >> >> >>>>>> Could you please explain in detail about Sec 3.2.2 update > >> >> >>>>>> > >> >> >>>>>> " o The actual mechanism of the identification is > depends > >> on > >> >> >SRC > >> >> >>>>>> policy." > >> >> >>>>>> > >> >> >>>>>> Thanks > >> >> >>>>>> partha > >> >> >>>>>> > >> >> >>>>>>> -----Original Message----- > >> >> >>>>>>> From: siprec-bounces@ietf.org > >> >> >>>>>>> [mailto:siprec-bounces@ietf.org] > >> >> On > >> >> >>>>>>> Behalf Of Leon Portman > >> >> >>>>>>> Sent: Tuesday, March 13, 2012 9:20 PM > >> >> >>>>>>> To: siprec@ietf.org > >> >> >>>>>>> Subject: Re: [siprec] I-D Action: > >> >> >>>>>>> draft-ietf-siprec-architecture-04.txt > >> >> >>>>>>> > >> >> >>>>>>> Main changes. They are mainly consist from Gonzalo and > >> >> >>>>>>> other mailing lists comments. > >> >> >>>>>>> > >> >> >>>>>>> 1. Definitions: Adding recording unaware UA definition > and > >> >> fixing > >> >> >>>>>>> some other definitions 2. Consistent abbreviation usage > in > >> >> >>>>>>> the > >> >> >>>>> document 3. > >> >> >>>>>>> Figures fixes 4. Adding policy mentions in Endpoint as > SRC > >> 5. > >> >> >>>>>>> Removing WEBRTC mentions 6. Adding more descriptions in > SRS > >> >> >>>>>>> initiated flows 7.Adding support for RS without metadata > >> >> >>>>>>> > >> >> >>>>>>> There are some small typo mistakes in v04. I have already > >> >> >>>>>>> fixed them and will update in next version > >> >> >>>>>>> > >> >> >>>>>>> Regards > >> >> >>>>>>> > >> >> >>>>>>> Leon > >> >> >>>>>>> > >> >> >>>>>>> -----Original Message----- > >> >> >>>>>>> From: siprec-bounces@ietf.org > >> >> >>>>>>> [mailto:siprec-bounces@ietf.org] > >> >> On > >> >> >>>>>>> Behalf Of internet-drafts@ietf.org > >> >> >>>>>>> Sent: Monday, March 12, 2012 3:25 PM > >> >> >>>>>>> To: i-d-announce@ietf.org > >> >> >>>>>>> Cc: siprec@ietf.org > >> >> >>>>>>> Subject: [siprec] I-D Action: > >> >> >>>>>>> draft-ietf-siprec-architecture-04.txt > >> >> >>>>>>> > >> >> >>>>>>> > >> >> >>>>>>> A New Internet-Draft is available from the on-line > >> >> >>>>>>> Internet-Drafts directories. This draft is a work item of > >> the > >> >> SIP > >> >> >>>>>>> Recording Working Group of the IETF. > >> >> >>>>>>> > >> >> >>>>>>> Title : An Architecture for Media Recordi= ng > >using > >> >> >the > >> >> >>>>>>> Session Initiation Protocol > >> >> >>>>>>> Author(s) : Andrew Hutton > >> >> >>>>>>> Leon Portman > >> >> >>>>>>> Rajnish Jain > >> >> >>>>>>> Ken Rehor > >> >> >>>>>>> Filename : draft-ietf-siprec-architecture- > >04.txt > >> >> >>>>>>> Pages : 16 > >> >> >>>>>>> Date : 2012-03-12 > >> >> >>>>>>> > >> >> >>>>>>> Session recording is a critical requirement in many > >> >> >>>>>>> communications environments such as call centers and > >> >> >>>>>>> financial trading. In some of these environments, all > >> >> >>>>>>> calls must be recorded for regulatory, compliance, and > >> >> >>>>>>> consumer protection reasons. Recording of a session is > >> >> >>>>>>> typically performed by sending a copy of a media stream > to > >> >> >>>>>>> a recording device. This document describes > architectures > >> >> >>>>>>> for deploying session > >> >> recording > >> >> >>>>>>> solutions in an environment which is based on the Session > >> >> >Initiation Protocol (SIP). > >> >> >>>>>>> > >> >> >>>>>>> > >> >> >>>>>>> A URL for this Internet-Draft is: > >> >> >>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-siprec- > >> >> architectur > >> >> >>>>>>> e- > >> >> >>>>>>> 04.txt > >> >> >>>>>>> > >> >> >>>>>>> Internet-Drafts are also available by anonymous FTP at: > >> >> >>>>>>> ftp://ftp.ietf.org/internet-drafts/ > >> >> >>>>>>> > >> >> >>>>>>> This Internet-Draft can be retrieved at: > >> >> >>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec- > >> >> architecture > >> >> >>>>>>> - > >> >> >>> 04. > >> >> >>>>>>> txt > >> >> >>>>>>> > >> >> >>>>>>> _______________________________________________ > >> >> >>>>>>> siprec mailing list > >> >> >>>>>>> siprec@ietf.org > >> >> >>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >> >> >>>>>>> _______________________________________________ > >> >> >>>>>>> siprec mailing list > >> >> >>>>>>> siprec@ietf.org > >> >> >>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >> >> >>>>>> _______________________________________________ > >> >> >>>>>> siprec mailing list > >> >> >>>>>> siprec@ietf.org > >> >> >>>>>> https://www.ietf.org/mailman/listinfo/siprec > >> >> >>>> > >> >> >> > >> >> > >> >> _______________________________________________ > >> >> 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 Mar 19 07:47:17 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6877D21F86A3 for ; Mon, 19 Mar 2012 07:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFX7zqw85dOP for ; Mon, 19 Mar 2012 07:47:16 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4C221F8692 for ; Mon, 19 Mar 2012 07:47:16 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Mon, 19 Mar 2012 16:47:14 +0200 From: Leon Portman To: "Hutton, Andrew" , "siprec@ietf.org" Date: Mon, 19 Mar 2012 16:47:13 +0200 Thread-Topic: RTCWeb DTLS-SRTP , SDES, RTP etc. Thread-Index: Ac0F3Xrq8q1zTRBYSIWJMv/wBq1wjAAAUlcA Message-ID: <07465C1D981ABC41A344374066AE1A2C39DB06C3D9@TLVMBX01.nice.com> References: <101C6067BEC68246B0C3F6843BCCC1E31296AE1E6D@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31296AE1E6D@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] RTCWeb DTLS-SRTP , SDES, RTP etc. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 19 Mar 2012 14:47:17 -0000 One of the issues that we have had with DTL-SRTP support in SRS in the past= , was long time required to establish DTLS-SRTP session for call-based reco= rding use case, which caused severe media clipping in the recording (second= s). Establishment of DTLS-SRTP session requires multiple messages and ackno= wledgement. Regards Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Hutton, Andrew Sent: Monday, March 19, 2012 4:35 PM To: siprec@ietf.org Subject: [siprec] RTCWeb DTLS-SRTP , SDES, RTP etc. Hi All, The RTCWeb working group are hoping to make a decision on the use of DTLS-S= RTP, SDES-SRTP and plain RTP at IETF83. This could well go in the direction= that RTCWeb clients only support DTLS-SRTP or at very least that DTLS-SRTP= is the preferred choice. I am interested in opinions as to whether we need to do more work in unders= tand the implication of recording communication session that use DTLS-SRTP = and if so where we should do this. Probably http://tools.ietf.org/html/draft-eckel-siprec-rtp-rec-03 is the pl= ace to do this if we need to. Any comments? Regards Andy _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From br@brianrosen.net Mon Mar 19 08:14:05 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C17521F87C7 for ; Mon, 19 Mar 2012 08:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.834 X-Spam-Level: X-Spam-Status: No, score=-101.834 tagged_above=-999 required=5 tests=[AWL=-0.724, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4aJIOeejPRv for ; Mon, 19 Mar 2012 08:14:04 -0700 (PDT) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by ietfa.amsl.com (Postfix) with ESMTP id 0827E21F87BD for ; Mon, 19 Mar 2012 08:14:04 -0700 (PDT) X-ASG-Debug-ID: 1332168715-04d035103def380001-sFFYAS Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id NfiSxio6esxTNpIw; Mon, 19 Mar 2012 07:51:55 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from [209.173.57.233] (helo=[192.168.130.23]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1S9dwB-003vkA-7Y; Mon, 19 Mar 2012 07:51:55 -0700 Mime-Version: 1.0 (Apple Message framework v1257) X-ASG-Orig-Subj: Re: [siprec] RTCWeb DTLS-SRTP , SDES, RTP etc. Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <07465C1D981ABC41A344374066AE1A2C39DB06C3D9@TLVMBX01.nice.com> Date: Mon, 19 Mar 2012 10:51:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <766B366B-1D02-4F9B-9BD4-17E9D6614646@brianrosen.net> References: <101C6067BEC68246B0C3F6843BCCC1E31296AE1E6D@MCHP058A.global-ad.net> <07465C1D981ABC41A344374066AE1A2C39DB06C3D9@TLVMBX01.nice.com> To: Leon Portman X-Mailer: Apple Mail (2.1257) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1332168715 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.12 X-Barracuda-Spam-Status: No, SCORE=0.12 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=CN_BODY_332 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.91672 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 Cc: "siprec@ietf.org" Subject: Re: [siprec] RTCWeb DTLS-SRTP , SDES, RTP etc. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 19 Mar 2012 15:14:05 -0000 Sounds right, and that's not fixable, right? You can't do something = similar to a persistent TLS connection to avoid a per call RSA exchange. Now, if the original call comes in DTLS SRTP, you can overlap the = creation of the recording stream DTLS-SRTP, which wouldn't be a problem. = It would be a problem if the original stream came either unencrypted, = or used SRTP with some other keying mechanism. Brian On Mar 19, 2012, at 10:47 AM, Leon Portman wrote: > One of the issues that we have had with DTL-SRTP support in SRS in the = past, was long time required to establish DTLS-SRTP session for = call-based recording use case, which caused severe media clipping in the = recording (seconds). Establishment of DTLS-SRTP session requires = multiple messages and acknowledgement. >=20 > Regards >=20 > Leon >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On = Behalf Of Hutton, Andrew > Sent: Monday, March 19, 2012 4:35 PM > To: siprec@ietf.org > Subject: [siprec] RTCWeb DTLS-SRTP , SDES, RTP etc. >=20 > Hi All, >=20 > The RTCWeb working group are hoping to make a decision on the use of = DTLS-SRTP, SDES-SRTP and plain RTP at IETF83. This could well go in the = direction that RTCWeb clients only support DTLS-SRTP or at very least = that DTLS-SRTP is the preferred choice. >=20 > I am interested in opinions as to whether we need to do more work in = understand the implication of recording communication session that use = DTLS-SRTP and if so where we should do this. >=20 > Probably http://tools.ietf.org/html/draft-eckel-siprec-rtp-rec-03 is = the place to do this if we need to. >=20 > Any comments? >=20 > Regards > Andy >=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 From Leon.Portman@nice.com Mon Mar 19 08:35:16 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAACB21F87AD for ; Mon, 19 Mar 2012 08:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptjQvqUcdtuf for ; Mon, 19 Mar 2012 08:35:15 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 7C67821F8798 for ; Mon, 19 Mar 2012 08:35:14 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Mon, 19 Mar 2012 17:35:13 +0200 From: Leon Portman To: Brian Rosen Date: Mon, 19 Mar 2012 17:35:12 +0200 Thread-Topic: [siprec] RTCWeb DTLS-SRTP , SDES, RTP etc. Thread-Index: Ac0F4u5ohdbIbmrNRjeBaIcZvbNWOAAAqFTg Message-ID: <07465C1D981ABC41A344374066AE1A2C39DB06C43C@TLVMBX01.nice.com> References: <101C6067BEC68246B0C3F6843BCCC1E31296AE1E6D@MCHP058A.global-ad.net> <07465C1D981ABC41A344374066AE1A2C39DB06C3D9@TLVMBX01.nice.com> <766B366B-1D02-4F9B-9BD4-17E9D6614646@brianrosen.net> In-Reply-To: <766B366B-1D02-4F9B-9BD4-17E9D6614646@brianrosen.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 Cc: "siprec@ietf.org" Subject: Re: [siprec] RTCWeb DTLS-SRTP , SDES, RTP etc. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 19 Mar 2012 15:35:16 -0000 We tried some optimizations with buffering but it was very complex. Theoretically, if both CS and RS need to establish DTLS-SRTP session in par= allel, clipping can b minimized however what if SRS is located remotely ( c= entral data center) and CS is local in the branch, then it will not work. Leon -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Monday, March 19, 2012 4:52 PM To: Leon Portman Cc: Hutton, Andrew; siprec@ietf.org Subject: Re: [siprec] RTCWeb DTLS-SRTP , SDES, RTP etc. Sounds right, and that's not fixable, right? You can't do something simila= r to a persistent TLS connection to avoid a per call RSA exchange. Now, if the original call comes in DTLS SRTP, you can overlap the creation = of the recording stream DTLS-SRTP, which wouldn't be a problem. It would b= e a problem if the original stream came either unencrypted, or used SRTP wi= th some other keying mechanism. Brian On Mar 19, 2012, at 10:47 AM, Leon Portman wrote: > One of the issues that we have had with DTL-SRTP support in SRS in the pa= st, was long time required to establish DTLS-SRTP session for call-based re= cording use case, which caused severe media clipping in the recording (seco= nds). Establishment of DTLS-SRTP session requires multiple messages and ack= nowledgement. >=20 > Regards >=20 > Leon >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf = Of Hutton, Andrew > Sent: Monday, March 19, 2012 4:35 PM > To: siprec@ietf.org > Subject: [siprec] RTCWeb DTLS-SRTP , SDES, RTP etc. >=20 > Hi All, >=20 > The RTCWeb working group are hoping to make a decision on the use of DTLS= -SRTP, SDES-SRTP and plain RTP at IETF83. This could well go in the directi= on that RTCWeb clients only support DTLS-SRTP or at very least that DTLS-SR= TP is the preferred choice. >=20 > I am interested in opinions as to whether we need to do more work in unde= rstand the implication of recording communication session that use DTLS-SRT= P and if so where we should do this. >=20 > Probably http://tools.ietf.org/html/draft-eckel-siprec-rtp-rec-03 is the = place to do this if we need to. >=20 > Any comments? >=20 > Regards > Andy >=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 From pravindran@sonusnet.com Mon Mar 19 23:53:03 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3096A21F866E for ; Mon, 19 Mar 2012 23:53:03 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxOb6HmI5+BT for ; Mon, 19 Mar 2012 23:53:02 -0700 (PDT) Received: from na3sys010aog109.obsmtp.com (na3sys010aog109.obsmtp.com [74.125.245.86]) by ietfa.amsl.com (Postfix) with ESMTP id E079E21F8664 for ; Mon, 19 Mar 2012 23:53:01 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob109.postini.com ([74.125.244.12]) with SMTP ID DSNKT2gpTOWezRNaoau44vW5v97rLuoahX2G@postini.com; Mon, 19 Mar 2012 23:53:02 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 20 Mar 2012 02:53:14 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Tue, 20 Mar 2012 12:22:54 +0530 From: "Ravindran, Parthasarathi" To: Leon Portman , Brian Rosen Thread-Topic: [siprec] RTCWeb DTLS-SRTP , SDES, RTP etc. Thread-Index: Ac0F3Xrq8q1zTRBYSIWJMv/wBq1wjAAAUlcA//+l34CAAAwkAP/+r6bQ Date: Tue, 20 Mar 2012 06:52:53 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E1FFF5B@inba-mail01.sonusnet.com> References: <101C6067BEC68246B0C3F6843BCCC1E31296AE1E6D@MCHP058A.global-ad.net> <07465C1D981ABC41A344374066AE1A2C39DB06C3D9@TLVMBX01.nice.com> <766B366B-1D02-4F9B-9BD4-17E9D6614646@brianrosen.net> <07465C1D981ABC41A344374066AE1A2C39DB06C43C@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C39DB06C43C@TLVMBX01.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.61] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] RTCWeb DTLS-SRTP , SDES, RTP etc. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2012 06:53:03 -0000 Andy, RTCWeb DTLS-SRTP in CS decision should not impact SIPREC for the following = reasons: 1) In case of SRC acts as RTP endpoint for CS and RS, DTLS-SRTP in CS or RS= does not matter much 2) SIPREC does not even enforce to have the different SDES keys for CS and = RS. It is perfectly fine to pass the same SDES key to RS as well as to the = remote participant. 3) SIPREC CS is scoped for SIP 4) SRTP-DTLS in RS SIP dialog should be no different than normal SIP SRTP-D= TLS session. In case you wish to mention that SRTP-DTLS as one of the mechanism in recor= ding media security, I'm fine. Thanks Partha=20 >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Leon Portman >Sent: Monday, March 19, 2012 9:05 PM >To: Brian Rosen >Cc: siprec@ietf.org >Subject: Re: [siprec] RTCWeb DTLS-SRTP , SDES, RTP etc. > >We tried some optimizations with buffering but it was very complex. > >Theoretically, if both CS and RS need to establish DTLS-SRTP session in >parallel, clipping can b minimized however what if SRS is located >remotely ( central data center) and CS is local in the branch, then it >will not work. > >Leon > >-----Original Message----- >From: Brian Rosen [mailto:br@brianrosen.net] >Sent: Monday, March 19, 2012 4:52 PM >To: Leon Portman >Cc: Hutton, Andrew; siprec@ietf.org >Subject: Re: [siprec] RTCWeb DTLS-SRTP , SDES, RTP etc. > > >Sounds right, and that's not fixable, right? You can't do something >similar to a persistent TLS connection to avoid a per call RSA exchange. > >Now, if the original call comes in DTLS SRTP, you can overlap the >creation of the recording stream DTLS-SRTP, which wouldn't be a problem. >It would be a problem if the original stream came either unencrypted, or >used SRTP with some other keying mechanism. > >Brian > >On Mar 19, 2012, at 10:47 AM, Leon Portman wrote: > >> One of the issues that we have had with DTL-SRTP support in SRS in the >past, was long time required to establish DTLS-SRTP session for call- >based recording use case, which caused severe media clipping in the >recording (seconds). Establishment of DTLS-SRTP session requires >multiple messages and acknowledgement. >> >> Regards >> >> Leon >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >Behalf Of Hutton, Andrew >> Sent: Monday, March 19, 2012 4:35 PM >> To: siprec@ietf.org >> Subject: [siprec] RTCWeb DTLS-SRTP , SDES, RTP etc. >> >> Hi All, >> >> The RTCWeb working group are hoping to make a decision on the use of >DTLS-SRTP, SDES-SRTP and plain RTP at IETF83. This could well go in the >direction that RTCWeb clients only support DTLS-SRTP or at very least >that DTLS-SRTP is the preferred choice. >> >> I am interested in opinions as to whether we need to do more work in >understand the implication of recording communication session that use >DTLS-SRTP and if so where we should do this. >> >> Probably http://tools.ietf.org/html/draft-eckel-siprec-rtp-rec-03 is >the place to do this if we need to. >> >> Any comments? >> >> 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 > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Tue Mar 20 04:03:13 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7385621F865F for ; Tue, 20 Mar 2012 04:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQhAXU+uvp+t for ; Tue, 20 Mar 2012 04:03:12 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 57A4B21F8622 for ; Tue, 20 Mar 2012 04:03:12 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 835F323F03EA for ; Tue, 20 Mar 2012 12:03:11 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 20 Mar 2012 12:03:11 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Date: Tue, 20 Mar 2012 12:03:10 +0100 Thread-Topic: SIPREC IETF83 Agenda. Thread-Index: Ac0GiQlN6wu2zxQZQDGso/v5IE68SA== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31296AE22B4@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] SIPREC IETF83 Agenda. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2012 11:03:13 -0000 Hi All, The final agenda has been posted (See http://www.ietf.org/proceedings/83/ag= enda/agenda-83-siprec.pdf) there are no changes from the previous draft. Could those of you presenting try to have your presentations prepared and s= ent to the chairs before the meeting. Doing so will really make your time a= t the meeting more enjoyable and less stressful. At the latest we should have the presentations by the close of play on Tues= day the 27th of March. Looking forward to seeing you all in Paris. Regards Andy (SIPREC Co-Chair). From eckelcu@cisco.com Fri Mar 23 02:14:28 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C987321F854A for ; Fri, 23 Mar 2012 02:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.367 X-Spam-Level: X-Spam-Status: No, score=-9.367 tagged_above=-999 required=5 tests=[AWL=1.232, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aws2m-fmVS8m for ; Fri, 23 Mar 2012 02:14:24 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB0321F84EA for ; Fri, 23 Mar 2012 02:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=3745; q=dns/txt; s=iport; t=1332494064; x=1333703664; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=JDZsuQSjp2CoKqsmbkB/vn9qgx9T4R42uNbFglxyt9o=; b=GG4YHQw9tsF/OEwzJXRxBoLGg7/k9qWQU2wB7xc40OWU84DuHsERFubc r4c/NZ2fdi9DfrYWm/JCBTprYV3IbyRl/pDm41f0iqVvVHvhY/oWkvwEZ 671JmiFKyrOg3uyQ78hyUPk0uFZnGJhvdGkuFERTABfoa8lpaXJup44qO M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPY9bE+rRDoH/2dsb2JhbABEuACBB4IJAQEBBAEBAQ8BHQo0FwQCAQgRAQMBAQsGFwEGASYfAwYIAQEEARIIGodnAQuec5cRBJAgYwSIVptJgWiDBw X-IronPort-AV: E=Sophos;i="4.73,636,1325462400"; d="scan'208";a="34239852" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 23 Mar 2012 09:14:23 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2N9EN3Z010591; Fri, 23 Mar 2012 09:14:23 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); Fri, 23 Mar 2012 02:14:23 -0700 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, 23 Mar 2012 02:14:22 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] WGLC on draft-ietf-siprec-architecture Thread-Index: Ac0Dmv2cHHcO9ke8SRWQREeDPOVpOAFFEWOA References: From: "Charles Eckel (eckelcu)" To: "Rosen, Brian" , X-OriginalArrivalTime: 23 Mar 2012 09:14:23.0249 (UTC) FILETIME=[564C0010:01CD08D5] Subject: Re: [siprec] WGLC on draft-ietf-siprec-architecture X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 23 Mar 2012 09:14:28 -0000 I think the draft is in pretty good shape. I do have the following comments (mostly minor). Globally replace: - "UA's" with "UAs" - "CSes" with "CSs" - "the SIPREC" with SIPREC" Section 1: Introduction s/this information in outside/this information is outside Section 2: Definitions Recording Aware User Agent s/ Such extensions may be used to notify the Recording aware UA that a session is being recorded or to all the Recording aware UA to express preferences .../ Such extensions may be used to notify the Recording aware UA that a session is being recorded, or by a Recording aware UA to express preferences ... Recording unaware User Agent (UA) s/or to express/or express s/that out of scope of the SIPREC/that is out of scope for SIPREC Replicated Media s/Recordin Session/Recording Session Section 3.1.1 reads, "The B2BUA/SRC is responsible for honoring any indication from recording aware UA's or through some configured policies that the communication session must not be recorded." This is not accurate. There is not a way for the UA to indicate that a session MUST not be recorded. Instead, the UA indicates its preference, and the SBC/B2BUA is not required to "honor" that preference. Section 3.1.4, the second paragraph is hard to parse. I suggest breaking it up a bit as follows: "The Session Recording Client and Session Recording Server described in this document may act as an application server as described in [RFC5567]; and therefore, when further decomposed, may be made up of an application server which uses a mediactrl interface to control a media server for the purpose of recording the media streams. However, this interface is considered outside the scope of this document." Section 3.2, the last paragraph currently reads, "Concerning media negotiation, regular SIP/SDP capabilities should be used, and existing transcoding capabilities should not be precluded" I suggest adding SRTP here as well, as follows: "Concerning media negotiation, regular SIP/SDP capabilities should be used, and existing transcoding capabilities and media encryption should not be precluded." Section 3.2.2, I think the reference to isfocus should be removed to avoid confusion. s/identification is depends/identification depends The reference to the Join header should be removed as well, although I think this comment was made already. Section 3.2.5 s/the more capable/a more capable Section 3.3.2, large paragraph, s/"it is also possible/It is also possible Section 4, IANA considerations. The architecture draft mentions SIP/SDP extensions. I think it would be useful to state that the associated IANA considerations will be addressed in the protocol draft that defines them. Section 5, s/make use/makes use s/are aware of that/are aware that s/recorded and the architecture/recorded, and the architecture Section 7, update the references to the protocol and metadata drafts Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Rosen, Brian > Sent: Friday, March 16, 2012 10:34 AM > To: siprec@ietf.org > Subject: [siprec] WGLC on draft-ietf-siprec-architecture >=20 > We would like to start working group last call on -architecture-04. > Normally, we would have a two week WGLC, but since the IETF meeting > falls in the middle, we will extend it to April 6th. >=20 > Please review the draft, even if you have looked at it before. Please > send comments to the list as soon as possible. >=20 > Brian >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From leon.portman@gmail.com Fri Mar 23 02:16:44 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E9821F8548 for ; Fri, 23 Mar 2012 02:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBrQD0FZUTTi for ; Fri, 23 Mar 2012 02:16:43 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2327C21F8547 for ; Fri, 23 Mar 2012 02:16:42 -0700 (PDT) Received: by werb10 with SMTP id b10so2982381wer.31 for ; Fri, 23 Mar 2012 02:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=BRJ4iiVbJlaaiZX2DvJtAPG8fj6zLwir8cKCWG3ttgM=; b=qd7e2lsXtZ+zl2Q6wkKjrSts6BhVz9OsF95v4n7ndfw0ohfDYyDbHv76KiTiYWmggg paNWuYlbZiFqH1iKMyeS1ResQfddWXlOJYWZDdrXGCmrPv0N63W0hClG3yZK8YYds/G1 FYS0VlnOtQWdLSskJ3zkKFfHhuMwwQ31Jipq/vVMqpa6TVyTJ7tCoJVywr5mCPno9Ugl cTvunT6A85+jeygDb/DJvtdzwcnPNA7/AKF2NKU/pQfxSVvoS+Z/2M/QU59oTZ9KuACr Hj6HV4GINHjaNpANGPYiMefnSiCi2dxaRymctwzy58Mr2/U9NtI7kpGacmUuWUqXfSJR 4R9g== Received: by 10.180.89.130 with SMTP id bo2mr4716408wib.17.1332494202251; Fri, 23 Mar 2012 02:16:42 -0700 (PDT) Received: from [192.168.14.68] (62-90-99-78.barak.net.il. [62.90.99.78]) by mx.google.com with ESMTPS id o2sm20532604wiv.11.2012.03.23.02.16.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Mar 2012 02:16:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1444\)) From: Leon Portman In-Reply-To: Date: Fri, 23 Mar 2012 11:16:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Charles Eckel (eckelcu) X-Mailer: Apple Mail (2.1444) Cc: "Rosen, Brian" , siprec@ietf.org Subject: Re: [siprec] WGLC on draft-ietf-siprec-architecture X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 23 Mar 2012 09:16:44 -0000 Charles Hi Thank you very much for the comments. Will update in the next version. Regards Leon On Mar 23, 2012, at 11:14 AM, Charles Eckel (eckelcu) = wrote: > I think the draft is in pretty good shape. I do have the following > comments (mostly minor). >=20 > Globally replace: > - "UA's" with "UAs" > - "CSes" with "CSs" > - "the SIPREC" with SIPREC" >=20 > Section 1: Introduction > s/this information in outside/this information is outside >=20 > Section 2: Definitions > Recording Aware User Agent > s/ > Such extensions may be used to notify the Recording aware UA that a > session is being recorded or to all the Recording aware UA to express > preferences .../ > Such extensions may be used to notify the Recording aware UA that a > session is being recorded, or by a Recording aware UA to express > preferences ... >=20 > Recording unaware User Agent (UA) > s/or to express/or express > s/that out of scope of the SIPREC/that is out of scope for SIPREC >=20 > Replicated Media > s/Recordin Session/Recording Session >=20 > Section 3.1.1 reads, > "The B2BUA/SRC is responsible for honoring any indication from > recording aware UA's or through some configured policies that the > communication session must not be recorded." > This is not accurate. There is not a way for the UA to indicate that a > session MUST not be recorded. Instead, the UA indicates its = preference, > and the SBC/B2BUA is not required to "honor" that preference. >=20 > Section 3.1.4, the second paragraph is hard to parse. I suggest = breaking > it up a bit as follows: > "The Session Recording Client and Session Recording Server described > in this document may act as an application server as described in > [RFC5567]; and therefore, when further decomposed, may be made up of = an > application server which uses a mediactrl interface to control a > media server for the purpose of recording the media streams. However, > this interface is considered outside the scope of this document." >=20 > Section 3.2, the last paragraph currently reads, > "Concerning media negotiation, regular SIP/SDP capabilities should be > used, and existing transcoding capabilities should not be precluded" > I suggest adding SRTP here as well, as follows: > "Concerning media negotiation, regular SIP/SDP capabilities should be > used, and existing transcoding capabilities and media encryption = should > not be precluded." >=20 > Section 3.2.2, I think the reference to isfocus should be removed to > avoid confusion. > s/identification is depends/identification depends >=20 > The reference to the Join header should be removed as well, although I > think this comment was made already. >=20 > Section 3.2.5 > s/the more capable/a more capable >=20 > Section 3.3.2, large paragraph, > s/"it is also possible/It is also possible >=20 > Section 4, IANA considerations. > The architecture draft mentions SIP/SDP extensions. I think it would = be > useful to state that the associated IANA considerations will be > addressed in the protocol draft that defines them. >=20 > Section 5, > s/make use/makes use > s/are aware of that/are aware that > s/recorded and the architecture/recorded, and the architecture >=20 > Section 7, update the references to the protocol and metadata drafts >=20 > Cheers, > Charles >=20 >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Rosen, Brian >> Sent: Friday, March 16, 2012 10:34 AM >> To: siprec@ietf.org >> Subject: [siprec] WGLC on draft-ietf-siprec-architecture >>=20 >> We would like to start working group last call on -architecture-04. >> Normally, we would have a two week WGLC, but since the IETF meeting >> falls in the middle, we will extend it to April 6th. >>=20 >> Please review the draft, even if you have looked at it before. = Please >> send comments to the list as soon as possible. >>=20 >> Brian >>=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 From pravindran@sonusnet.com Sat Mar 24 07:53:38 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A77B21F86C2 for ; Sat, 24 Mar 2012 07:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.043 X-Spam-Level: X-Spam-Status: No, score=-5.043 tagged_above=-999 required=5 tests=[AWL=1.556, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R83KCu6+HeUb for ; Sat, 24 Mar 2012 07:53:38 -0700 (PDT) Received: from na3sys010aog109.obsmtp.com (na3sys010aog109.obsmtp.com [74.125.245.86]) by ietfa.amsl.com (Postfix) with ESMTP id A06A721F86C1 for ; Sat, 24 Mar 2012 07:53:37 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob109.postini.com ([74.125.244.12]) with SMTP ID DSNKT23f8NGClSeItUr7hYTPGs6roEtRI9D4@postini.com; Sat, 24 Mar 2012 07:53:37 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sat, 24 Mar 2012 10:53:53 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Sat, 24 Mar 2012 20:23:32 +0530 From: "Ravindran, Parthasarathi" To: "siprec@ietf.org" Thread-Topic: Editoral comment: CSRS association addition in Metadata model Thread-Index: Ac0JQASmsF3ZiW4PSFWKTPYxxUNyWQ== Date: Sat, 24 Mar 2012 14:53:50 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E21FC6B@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Editoral comment: CSRS association addition in Metadata model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 14:53:38 -0000 Hi all, CSRS association has to be added in Sec 4 Figure.=20 Please let me know in case anybody has objection for this. Thanks Partha=20 From eckelcu@cisco.com Sat Mar 24 10:11:25 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA01521F85AA for ; Sat, 24 Mar 2012 10:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.414 X-Spam-Level: X-Spam-Status: No, score=-9.414 tagged_above=-999 required=5 tests=[AWL=1.185, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebnK6IMV7EIR for ; Sat, 24 Mar 2012 10:11:25 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 05E6C21F8573 for ; Sat, 24 Mar 2012 10:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2089; q=dns/txt; s=iport; t=1332609084; x=1333818684; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=5g8NNybJ/Ll1QSW4b8HOmJ4u8cdyCeMO9dUtuGGI1Zo=; b=BTuub5qjssZmBdiStDMc3OMhBl9uDw1QF5wr8UM59Cgh/vC4YVE/shBr 0pgGxLyHfEuJX3kdsDp1c1kgoRUg1rrsdTws4LJ/25YY5lhUWwO98/7aG mUn+T97q1d0rKKs6kGpPXy5AZyzJp5dRU8uFXKjGeymnHoIPLhgxRH4zS I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOL+bU+rRDoG/2dsb2JhbAA6CrgggQeCCwEEEgEdClEBKgYYB1cBBBsah2cBmC+BJ544il6DJoJBYwSIV5tOgWiDBw X-IronPort-AV: E=Sophos;i="4.73,642,1325462400"; d="scan'208";a="34401601" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 24 Mar 2012 17:11:24 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2OHBO21007854 for ; Sat, 24 Mar 2012 17:11:24 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); Sat, 24 Mar 2012 10:11:24 -0700 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: Sat, 24 Mar 2012 10:11:22 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on draft-ietf-siprec-protocol-03 Thread-Index: Ac0J4SMaV3862oY6QV++gVxZ3BGhBg== From: "Charles Eckel (eckelcu)" To: X-OriginalArrivalTime: 24 Mar 2012 17:11:24.0606 (UTC) FILETIME=[245E3DE0:01CD09E1] Subject: [siprec] comments on draft-ietf-siprec-protocol-03 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 17:11:25 -0000 Section 4.1, fifth paragraph describes an SRC using a single RS to record multiple CSs. However, it some places it uses "calls" instead of "CS". I think these should be changed to "CS". Section 4.2 reads, "Subsequent metadata updates can be represented as a stream of events in INVITE and UPDATE requests". Here and elsewhere in this section, I suggest avoiding this use of "stream". Perhaps replace with, "Subsequent metadata updates can be communicated in subsequent INVITE or UPDATE requests." Also, last sentence, change SRS to SRC. Figure 3: Delivering metadata via SIP UDPATE. The initial metadata deliver is via INVITE. Perhaps label simply as "Delivering metadata". Section 5.1 and 5.2, we do not use the From/To to identify the SRS/SRC. We use feature tags. The use of the feature tag +sip.src and +sip.src mean the SRC/SRS is capable of acting as an SRC/SRS, not that it is in this call. Perhaps use Accept-Contact: *;require;+sip.src or Accept-Contact: *;require;+sip.srs to indicate that the answerer must act as an SRC/SRS? Figure 4, second video m-line is labeled as audio. Section 8.1, I find the description of the partial update sending scenarios by the SRC to be very confusion. Isn't if sufficient to say that snapshot requires SDP and partial may not? Section 10.2.1, definition of paused,=20 s/progress by media/progress but media The last sentence read, "This attribute is also not used as an indication to negotiate which SRC in the call path will perform recording and is not used as a request to start/stop recording if there are multiple SRCs in the call path." I suggest replacing with, "This attribute is not used to negotiate which SRC in the call path will perform recording." Section 11.2.1 and 11.2.2 Is the appropriate value really "boolean"? Also, I think have the SRC include the +sip.src in INVITEs for CSs being useful to indicate to UAs that the call can be recorded. Section 11.3, why is this needed? Section 11.4.1, should "rs-metadata" be "rs-metadata+xml" instead? Cheers, Charles =20 From rmohanr@cisco.com Sat Mar 24 22:50:50 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43D721F8597 for ; Sat, 24 Mar 2012 22:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.305 X-Spam-Level: X-Spam-Status: No, score=-9.305 tagged_above=-999 required=5 tests=[AWL=0.695, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dq25o6x8Zlze for ; Sat, 24 Mar 2012 22:50:50 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3C85021F8596 for ; Sat, 24 Mar 2012 22:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=723; q=dns/txt; s=iport; t=1332654650; x=1333864250; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=8pJSg6ETbNHzPDP+Kh7WlZs+0R5qxBEhNtmdlX5CL9Y=; b=VSv1e0CHne7/lMJ0jvyLGUcEriV0Oi1sa5hXQyQuGtZV/tU749z190yB ukvCev6kssX6CmkSf1jMBSPU7zhmueswAJuaKh6zDPH7dfZiaPQu5YkEe th3EN9mh9wO6lerPZmzfdTXhemmxPUd95s5KmoP02zJArJfOdJfXQmkce A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKqxbk+tJV2d/2dsb2JhbABFuCKBB4IJAQEBBAEBAQ8BHQo0FwQCAQgRBAEBCwYXAQYBJh8JCAEBBAEKCAgah2gLmW2eBgSQRWMEiFWbUIFogm8 X-IronPort-AV: E=Sophos;i="4.73,646,1325462400"; d="scan'208,223";a="69189657" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 25 Mar 2012 05:50:49 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2P5omfO023655; Sun, 25 Mar 2012 05:50:49 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); Sun, 25 Mar 2012 11:20:47 +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: Sun, 25 Mar 2012 11:20:46 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD09FFF3B8@XMB-BGL-417.cisco.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E21FC6B@inba-mail01.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Editoral comment: CSRS association addition in Metadatamodel Thread-Index: Ac0JQASmsF3ZiW4PSFWKTPYxxUNyWQBCx+Mg References: <387F9047F55E8C42850AD6B3A7A03C6C0E21FC6B@inba-mail01.sonusnet.com> From: "Ram Mohan R (rmohanr)" To: "Ravindran, Parthasarathi" , X-OriginalArrivalTime: 25 Mar 2012 05:50:47.0970 (UTC) FILETIME=[3A3FD820:01CD0A4B] Subject: Re: [siprec] Editoral comment: CSRS association addition in Metadatamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 05:50:51 -0000 >From the last meeting(IEF 82) we agreed to have this association. So IMO we should incorporate this in the draft. Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ravindran, Parthasarathi > Sent: Saturday, March 24, 2012 8:24 PM > To: siprec@ietf.org > Subject: [siprec] Editoral comment: CSRS association addition in > Metadatamodel >=20 > Hi all, >=20 > CSRS association has to be added in Sec 4 Figure. >=20 > Please let me know in case anybody has objection for this. >=20 > Thanks > Partha > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pravindran@sonusnet.com Sun Mar 25 00:59:43 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBEC21F85C4 for ; Sun, 25 Mar 2012 00:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.47 X-Spam-Level: X-Spam-Status: No, score=-4.47 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, J_CHICKENPOX_61=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRJW0iahFOlj for ; Sun, 25 Mar 2012 00:59:41 -0700 (PDT) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with ESMTP id B4E4E21F85C0 for ; Sun, 25 Mar 2012 00:59:40 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKT27QbJEdKhBAHWlkqHE4oVz77Wfw0PpP@postini.com; Sun, 25 Mar 2012 00:59:40 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sun, 25 Mar 2012 03:59:56 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Sun, 25 Mar 2012 13:29:35 +0530 From: "Ravindran, Parthasarathi" To: "Hutton, Andrew" , Paul Kyzivat , "john.2.stafford@bt.com" Thread-Topic: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream Thread-Index: AQHM9u5+fndjjd+/FkOIx8G3Z8JvJpZToyqAgAAsYgCAANXBkIAAexrygAA9IwCABjc4AIAAYQQAgAXFX4CABNhngIAABb0AgAEz/QCAAErPgIAAEFwAgBKid9A= Date: Sun, 25 Mar 2012 07:59:52 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E21FE10@inba-mail01.sonusnet.com> References: , <4F4E43D3.8070508@alum.mit.edu> , <387F9047F55E8C42850AD6B3A7A03C6C0E068E45@inba-mail01.sonusnet.com> , <4F4FB6EA.8050203@alum.mit.edu> <4F553F1C.9070400@alum.mit.edu>, <101C6067BEC68246B0C3F6843BCCC1E312946BC5E3@MCHP058A.global-ad.net> <67DAF295CD01EB44AE6EA8A51F6ABF0A408C436093@EMV62-UKRD.domain1.systemhost.net>, <4F5E2BC2.8060708@alum.mit.edu> <4F5F6CDF.9040004@alum.mit.edu> <101C6067BEC68246B0C3F6843BCCC1E312967840E2@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312967840E2@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 07:59:43 -0000 Hi John, Looking at the current problem statement, ISTM that it is possible to accom= modate this scenario within the current metadata model. The point to be not= ed is that single stream shall be linked to multiple CS as per metadata mod= el (n CS to 1 stream association) and also, there is no means to identify t= he contributor of the mixed stream using metadata.=20 Please let me know in case the current metadata model does not help to fit = your scenario. Thanks Partha >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Hutton, Andrew >Sent: Tuesday, March 13, 2012 10:19 PM >To: Paul Kyzivat; john.2.stafford@bt.com >Cc: siprec@ietf.org >Subject: Re: [siprec] How to specify in metadata that multiple CS's are >being recorded in a single mixed RS m line stream > >Hi John, > >I agree with Paul's conclusions below. > >If the current metadata model does not fit your requirements then I >would encourage you to make a proposal for changes to the metadata model >and we can then discuss the proposal in the working group. > >Will you be in the Paris meeting? > >Regards >Andy > > > > > > > > > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: 13 March 2012 15:51 >> To: john.2.stafford@bt.com >> Cc: siprec@ietf.org >> Subject: Re: [siprec] How to specify in metadata that multiple CS's >> are being recorded in a single mixed RS m line stream >> >> John, >> >> Thanks for the explanation. I think I now know more than I want to. >> :-) This is clearly a very specialized situation. One we certainly >> didn't contemplate in our definitions. Without further study and >> discussion I don't really know what the best way to map this is, or if >> there is a best way. >> >> My first reaction is to suggest that you map what you have onto our >> model the best you can - making this an application issue. (E.g. >> simply consider each of your mixes to be a CS with multiple >> participants.) >> >> If that doesn't work, and you feel that changes to the model would >> make it easier for you to map to, then certainly feel free to propose >> changes to the model. But if you do so, please propose something that >> makes sense in its own right, independent of your specialized >> application. >> >> Thanks, >> Paul >> >> On 3/13/12 7:23 AM, john.2.stafford@bt.com wrote: >> > Paul, >> > >> > Ok let me have a go at explaining Finlay;s clarification! >> > >> > Handset 1 and Handset 2 are phone handsets, both work independantly >> like having 2 phones, but are both integrated into one turret. >> > >> > Speaker does mean loudspeaker, a trader can have many channels of >> audio he is listening to simultaneously via loudspeakers, these >> channels need to be recorded. >> > However these are not receive only channels, the turret has a single >> stalk microphone for talking back on the speaker channels. The trader >> can set the microphone to be connected to one, or multiple speaker >> channels simultaneously, and the mic can be always on or press to >talk. >> > >> > So each handset and each of the speakers channels is a separate CS. >> The trader will be a participant in each CS. >> > >> > The recorded mixes do not have to be de-multiplexed, they rely on >> > the >> human ears ability to hear distinquish participants on replay, >> > There is not sufficient information recorded to be able to de- >> multiplex the audio mix for replay. >> > >> > In Finlays example where there are 8 speaker channels, they are as >> > he >> shows typically mixed 4:1 . >> > They could also be mixed 2:1, in which case there would be 4 >> > recorder >> streams for the speakers, >> > or even 8:1 giving just 1 record channel. >> > >> > The mix ratio is determined by how busy the channels are, ie if >> > they >> are stock prices which may be shouted on a channel maybe only one a >> minute then you could mix 8 channsla nd still expect on replay to be >> able to hear what was being said. But if the channels have continuous >> commentary then you may only be able to mix 2:1. >> > It's a trade off of recorded/network bandwidth/cost against replay >> intelligibility. >> > >> > >> > >> > I think allowing a stream to have multiple session's (would have to >> be elements not an attribute) would allow the recorded to find a mixed >> recorded CS, >> > but I am at a loss of what to do about the paticipants >> lement, as a participant clearly does not recv the mixed stream. >> > >> > Hope that helps. >> > >> > Rgds >> > John Stafford | Solution Architect 1 | BT Global Services | Tel:+44 >> (0)1932 773504 | E: john.2.stafford@bt.com | >> www.bt.com/globalservices >> > ________________________________________ >> > From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of >> Paul Kyzivat [pkyzivat@alum.mit.edu] >> > Sent: 12 March 2012 17:00 >> > To: siprec@ietf.org >> > Subject: Re: [siprec] How to specify in metadata that multiple CS's >> are being recorded in a single mixed RS m line stream >> > >> > On 3/12/12 12:40 PM, finlay.fraser@bt.com wrote: >> >> Guys >> >> >> >> As a bit of background to this Trading turrets can have between 1 >> and 28 audio streams coming into them all of them require recording. >> >> >> >> To reduce recording costs trading companies have mixed devices to >> reduce VR license costs, network bandwidth, Storage >> >> >> >> Typically there would be two handsets and 8 speakers as follows:- >> >> >> >> Mix 1 - (Handset 1 RX and TX + Handset 2 RX and TX) Mix 2 - >> >> (Speaker 1 RX and TX + Speaker 2 RX and TX + Speaker 3 RX >> and TX + Speaker 4 RX and TX) >> >> Mix 3 - (Speaker 5 RX and TX + Speaker 6 RX and TX + Speaker 7 RX >> and TX + Speaker 8 RX and TX) >> > >> > First, can we clarify the terminology? >> > I guess Handset 1 and 2 refer to handsets used by the Trader? >> > And "Speaker" doesn't mean "loudspeaker", but rather designates a >> > participant connected to the Trader? >> > So there are 8 CSs, each involving the Trader and one of the >> Speakers? >> > And each Speaker can hear only the Trader, not any of the other >> > Speakers? (Ignoring unintended crosstalk.) >> > >> > Is each CS connected uniquely to one of the handsets? >> > Or can either handset be connected to any of the Speakers? >> > >> > Do Mix 2 and Mix 3 assume that only one of the speakers in the mix >> > is active at any one time? >> > >> >> So in SIPREC we have one RS for a Turret which in the example above >> can have 10 active CS these are being sent as 3 RTP streams >> >> or 3 m-lines to the recoding capture devices. >> >> >> >> The compliance officers in the bank have accepted the mixing so >> there is no requirement for the voice recorder to unmix the received >> streams they are stored >> >> and tagged. Normally the recorder is also taking a CTI feed and it >> just matches the tag normally a timestamp to the audio file in a many >> to one arrangement. >> > >> > Is there sufficient info in these mixes that the audio for each end >> of >> > any one CS can be accurately reconstructed? (Even though there is no >> > requirement that this be done? >> > >> > Thanks, >> > Paul >> > >> >> I hope this makes things a bit clearer >> >> >> >> Finlay >> >> ________________________________________ >> >> From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf >> >> Of >> Hutton, Andrew [andrew.hutton@siemens-enterprise.com] >> >> Sent: 09 March 2012 14:40 >> >> To: Stafford,J,John,JRJ3X C >> >> Cc: siprec@ietf.org >> >> Subject: Re: [siprec] How to specify in metadata that multiple CS's >> are being recorded in a single mixed RS m line stream >> >> >> >> Hi John, >> >> >> >> I am also struggling to understand this use case. >> >> >> >> If you mean that you want to have the SRC act as an RTP Mixer and >> mix the streams from different CS's in to a single RTP Session using >> the CSRC to demultiplex at the SRS then I think this is not supported >> by the current metadata model. >> >> >> >> Could our metadata experts please confirm? >> >> >> >> Regards >> >> Andy >> >> >> >> >> >> >> >>> -----Original Message----- >> >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> >>> Behalf Of Paul Kyzivat >> >>> Sent: 05 March 2012 22:33 >> >>> To: john.2.stafford@bt.com >> >>> Cc: siprec@ietf.org >> >>> Subject: Re: [siprec] How to specify in metadata that multiple >> >>> CS's >> are >> >>> being recorded in a single mixed RS m line stream >> >>> >> >>> On 3/5/12 11:45 AM, john.2.stafford@bt.com wrote: >> >>>> Ok, CSG is not a concern. >> >>>> >> >>>> What I wanted clarified was how metadatas and would look >> when >> >>> you have two simultaneous calls on an endpoint and both calls are >> mixed >> >>> into a single recorder stream. >> >>>> >> >>>> If represents the mixed stream of two calls going to >> the >> >>> recorder, then how can a participant have a that >> references that >> >>> stream, >> >>>> as a participant does NOT recv the mixed stream. >> >>> >> >>> I don't understand how it makes sense to mix the media for two >> distinct >> >>> calls. >> >>> >> >>> Or do you mean that you want to send them both over a single RTP >> >>> session, distinguished by SSRC or CSRC? >> >>> >> >>> Thanks, >> >>> Paul >> >>> >> >>>> >> >>>> Rgds >> >>>> John Stafford | Solution Architect 1 | BT Global Services >> >>>> ________________________________________ >> >>>> From: Paul Kyzivat [pkyzivat@alum.mit.edu] >> >>>> Sent: 01 March 2012 17:50 >> >>>> To: Stafford,J,John,JRJ3X C >> >>>> Cc: pravindran@sonusnet.com; siprec@ietf.org >> >>>> Subject: Re: [siprec] How to specify in metadata that multiple >> CS's >> >>> are being recorded in a single mixed RS m line stream >> >>>> >> >>>> On 3/1/12 3:53 AM, john.2.stafford@bt.com wrote: >> >>>>> Partha, >> >>>>> >> >>>>> I cant see how using CSG will help with the describing of the >> >>> streams. >> >>>>> Also I'm not convinced this would be the correct usage of a CSG, >> as >> >>> while the calls are associated as they are made by the same >> >>> person, >> in >> >>> terms of sip they are completely unrelated. >> >>>>> I think draft-ietf-metadata could do with an explanation of what >> >>> relationships a CSG implies. >> >>>> >> >>>> Its your call whether these calls are related in a way that you >> want >> >>> to >> >>>> track as a CSG. >> >>>> >> >>>> Clearly there are a number of different reasons you might want to >> >>> group >> >>>> CSs, and we currently don't provide any attributes to distinguish >> one >> >>>> reason from another. That is mostly because we didn't want to get >> >>> into >> >>>> the business of enumerating the possible uses. The solution to >> that >> >>> is >> >>>> to add proprietary extension data to the CSG and/or the CSs to >> >>> identify >> >>>> why they are grouped. >> >>>> >> >>>> Alternatively I would simply treat these as two separate CSs, >> >>>> each >> >>> with >> >>>> a separate media stream. >> >>>> >> >>>> Thanks, >> >>>> Paul >> >>>> >> >>>>> Rgds >> >>>>> John Stafford | Solution Architect 1 | BT Global Services >> >>>>> ________________________________________ >> >>>>> From: Ravindran, Parthasarathi [pravindran@sonusnet.com] >> >>>>> Sent: 01 March 2012 01:31 >> >>>>> To: Stafford,J,John,JRJ3X C; pkyzivat@alum.mit.edu; >> siprec@ietf.org >> >>>>> Subject: RE: [siprec] How to specify in metadata that multiple >> CS's >> >>> are being recorded in a single mixed RS m line stream >> >>>>> >> >>>>> John, >> >>>>> >> >>>>> I guess that you are looking for group (CSG) element usage. >> Person >> >>> AC sessions has to be grouped under single group. CS AC-B has to >> >>> be mentioned as one of the session in group and CS AC-D has to be >> >>> mentioned as another session of the group. Here, user AC is >> available >> >>> in both sessions wherein participant (device) A is in session1 and >> >>> participant (device) C is in session2, it is possible to pass >> >>> participant name as AC in both sessions and it is perfectly fine. >> >>> Please let me know whether this approach solves your problem. >> >>>>> >> >>>>> Thanks >> >>>>> Partha >> >>>>> >> >>>>>> -----Original Message----- >> >>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] >> On >> >>> Behalf >> >>>>>> Of john.2.stafford@bt.com >> >>>>>> Sent: Wednesday, February 29, 2012 11:36 PM >> >>>>>> To: pkyzivat@alum.mit.edu; siprec@ietf.org >> >>>>>> Subject: Re: [siprec] How to specify in metadata that multiple >> CS's >> >>> are >> >>>>>> being recorded in a single mixed RS m line stream >> >>>>>> >> >>>>>> Paul, >> >>>>>> >> >>>>>> Its one person AC with two handsets both in use at same time, >> >>> probably >> >>>>>> one to each ear. >> >>>>>> >> >>>>>> Rgds >> >>>>>> John Stafford | Solution Architect 1 | BT Global Services >> >>>>>> ________________________________________ >> >>>>>> From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On >> Behalf >> >>> Of >> >>>>>> Paul Kyzivat [pkyzivat@alum.mit.edu] >> >>>>>> Sent: 29 February 2012 15:27 >> >>>>>> To: siprec@ietf.org >> >>>>>> Subject: Re: [siprec] How to specify in metadata that multiple >> CS's >> >>> are >> >>>>>> being recorded in a single mixed RS m line stream >> >>>>>> >> >>>>>> On 2/29/12 9:29 AM, john.2.stafford@bt.com wrote: >> >>>>>>> A converse of the "How to specify in metadata that a >> participants >> >>>>>> stream is being recorded in multiple m line streams" thread: >> >>>>>>> >> >>>>>>> Another of our record configurations is when a turret's >> handset 1 >> >>> and >> >>>>>>> handset 2 calls are recorded as a single mixed recorder stream >> >>>>>>> >> >>>>>>> once again a persistent RS will be set up at registration >> >>>>>>> time, >> in >> >>>>>> this case there will be a single m line. >> >>>>>>> >> >>>>>>> So if represents a record stream, how would the >> >>> following be >> >>>>>> described in metadata: >> >>>>>>> >> >>>>>>> There are 2 calls, A-B and C-D, both are recorded via a >> >>>>>>> single >> >>>>>> stream. >> >>>>>>> participants A and C are the same person, making two calls on >> >>> handset >> >>>>>> 1 and handset 2 of their turret. >> >>>>>> >> >>>>>> Just to clarify: >> >>>>>> >> >>>>>> There is one person, call him AC, that has two handsets A and >C. >> >>>>>> AC has established one call with B (CS-A-B) and another call >> with D >> >>> (CS- >> >>>>>> C-D). >> >>>>>> >> >>>>>> I gather these calls go on in parallel. (Maybe AC is switching >> back >> >>> and >> >>>>>> forth taking into one handset of the other. In principal he >> could >> >>> put >> >>>>>> one to each ear and use both at the same time.) >> >>>>>> >> >>>>>> Or is this more like a two line phone, with radio buttons to >> switch >> >>>>>> between the two lines, so that at any given time one is active >> and >> >>> the >> >>>>>> other is "on hold"? >> >>>>>> >> >>>>>> I won't even try to respond to the stuff below until I get >> clarity >> >>> on >> >>>>>> the above. >> >>>>>> >> >>>>>> Thanks, >> >>>>>> Paul >> >>>>>> >> >>>>>>> The problems I have in describing this in metadata are: >> >>>>>>> 1. I dont know how to show what the participants, as >> >>>>>>> they >> >>> dont >> >>>>>> recv the 2 call mixed stream. >> >>>>>>> 2. I only have a single stream being recorded which includes 2 >> >>> CS's, >> >>>>>>> but the element can only have a single session >> >>> attriibute >> >>>>>>> >> >>>>>>> I can only describe this using >> >>>>>> and. I have not been following the >> list >> >>> too >> >>>>>> closely for the past couple of months, is it still the >> >>>>>> intention >> to >> >>> use >> >>>>>> these elements, as I see there is not yet a >> >>>>>> draft-ietf-metadata- >> >>> 06.txt >> >>>>>> that includes these elements in xml schema and examples. >> >>>>>>> >> >>>>>>> Also I dont know what happens to when >> using >> >>>>>> associations. >> >>>>>>> >> >>>>>>> Anyway, heres my stab at it, >> >>>>>>> >> >>>>>>> >> >>>>>>> > xmlns=3D'urn:ietf:params:xml:ns:recording'> >> >>>>>>> complete >> >>>>>>> >> >>>>>>> >> >>>>>>> > >>>>>>> id=3D"=3D=3DPARTICIPANT_A=3D=3D" >> >>>>>>> >> >>>>>>> > >>>>>>> xml:lang=3D"it">RamMohan >> >>> R >> >>>>>>> >> >>>>>>> >> >>>>>>> > >>>>>>> participant=3D"=3D=3DPARTICIPANT_A=3D=3D" >> >>>>>>> session=3D"=3D=3D=3D=3DSESSION_ONE=3D=3D=3D= =3D=3D"> >> >>>>>>> 2010-12- >> >>> 16T23:41:07Z> >>>>>> time> >> >>>>>>> TBD >> >>>>>>> >> >>>>>>> > >>>>>>> participant=3D"=3D=3DPARTICIPANT_A=3D=3D" >> >>>>>>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> >> >>>>>>> 2010-12- >> >>> 16T23:41:07Z> >>>>>> time> >> >>>>>>> >> >>>>>>> >> >>>>>>> > >>>>>>> id=3D"=3D=3DPARTICIPANT_B=3D=3D" >> >>>>>>> >> >>>>>>> Paul >> >>> Kyzivat >> >>>>>>> >> >>>>>>> >> >>>>>>> > >>>>>>> participant=3D"=3D=3DPARTICIPANT_B=3D=3D" >> >>>>>>> session=3D"=3D=3D=3D=3DSESSION_ONE=3D=3D=3D= =3D=3D"> >> >>>>>>> 2010-12- >> >>> 16T23:41:07Z> >>>>>> time> >> >>>>>>> TBD >> >>>>>>> >> >>>>>>> > >>>>>>> participant=3D"=3D=3DPARTICIPANT_B=3D=3D" >> >>>>>>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> >> >>>>>>> 2010-12- >> >>> 16T23:41:07Z> >>>>>> time> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> > >>>>>>> id=3D"=3D=3DPARTICIPANT_C=3D=3D" >> >>>>>>> >> >>>>>>> > >>>>>>> xml:lang=3D"it">RamMohan >> >>> R >> >>>>>>> >> >>>>>>> >> >>>>>>> > >>>>>>> participant=3D"=3D=3DPARTICIPANT_C=3D=3D" >> >>>>>>> session=3D"=3D=3D=3D=3DSESSION_TWO=3D=3D=3D= =3D=3D"> >> >>>>>>> 2010-12- >> >>> 16T22:02:04Z> >>>>>> time> >> >>>>>>> TBD >> >>>>>>> >> >>>>>>> > >>>>>>> participant=3D"=3D=3DPARTICIPANT_C=3D=3D" >> >>>>>>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> >> >>>>>>> 2010-12- >> >>> 16T22:02:04Z> >>>>>> time> >> >>>>>>> >> >>>>>>> >> >>>>>>> > >>>>>>> id=3D"=3D=3DPARTICIPANT_D=3D=3D" >> >>>>>>> >> >>>>>>> Andrew >> >>>>>> Hutton >> >>>>>>> >> >>>>>>> >> >>>>>>> > >>>>>>> participant=3D"=3D=3DPARTICIPANT_D=3D=3D" >> >>>>>>> session=3D"=3D=3D=3D=3DSESSION_TWO=3D=3D=3D= =3D=3D"> >> >>>>>>> 2010-12- >> >>> 16T22:02:04Z> >>>>>> time> >> >>>>>>> TBD >> >>>>>>> >> >>>>>>> > >>>>>>> participant=3D"=3D=3DPARTICIPANT_D=3D=3D" >> >>>>>>> stream =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"> >> >>>>>>> 2010-12- >> >>> 16T22:02:04Z> >>>>>> time> >> >>>>>>> >> >>>>>>> >> >>>>>>> > >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> Rgds >> >>>>>>> John Stafford | Solution Architect 1 | BT Global Services >> >>>>>>> _______________________________________________ >> >>>>>>> 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 >> >> _______________________________________________ >> >> 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 >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Mon Mar 26 03:14:30 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F88321F858F for ; Mon, 26 Mar 2012 03:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.641 X-Spam-Level: X-Spam-Status: No, score=-9.641 tagged_above=-999 required=5 tests=[AWL=0.958, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1t4i-X1Q6psJ for ; Mon, 26 Mar 2012 03:14:29 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 667C121F8559 for ; Mon, 26 Mar 2012 03:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=2592; q=dns/txt; s=iport; t=1332756868; x=1333966468; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=8HYN9q+LPVusso5hyXw84yuSwfNeAhRWz71hRpKyXj8=; b=TosIcuGqoiOu2DGWwpJbHzLzVm1zvnFaAgNlE9UPiZRPWKWodDNPf/7g emORwooYBQrpjtEQ6wumbRFZJWXM722yhlctPiUI8Ia0xCJGvA5UIjtX1 u1XoSbWOjcyN4V2ktyrAZkwuHjTumH04SN7dvI2ngL+94Q00159j0w52G M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAMdAcE9Io8UY/2dsb2JhbABDuUKCCQEBAQQBAQEPAR0KNBcEAgEIEQEDAQELBhcBBgEmHwMGCAEBBAsICBqHaAufAJZfBI4EgkFjBIhVm1CBaIJv X-IronPort-AV: E=Sophos;i="4.73,649,1325462400"; d="scan'208";a="8610774" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 26 Mar 2012 10:14:26 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2QAEQ3v007185 for ; Mon, 26 Mar 2012 10:14:26 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); Mon, 26 Mar 2012 15:44: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: Mon, 26 Mar 2012 15:44:02 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD0A1492D6@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] WGLC on draft-ietf-siprec-architecture Thread-Index: Ac0Dmv2cHHcO9ke8SRWQREeDPOVpOAHmSYpQ References: From: "Ram Mohan R (rmohanr)" To: X-OriginalArrivalTime: 26 Mar 2012 10:14:26.0144 (UTC) FILETIME=[39076600:01CD0B39] Subject: Re: [siprec] WGLC on draft-ietf-siprec-architecture X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 26 Mar 2012 10:14:30 -0000 Leon et al, Here are my comments. The document is pretty good shape and most of the comments are minor ones. s/Media Recording Metadata /Recording Metadata at all places in the document. We have not used Media Recording Metadata anywhere in the metadata draft. I think we can have consistent naming across documents wherever possible. The definitions of SRC, SRS, CS in section 2 is all repetition of what is already there in RFC 6341. Can we remove them ? In case you still want to retain them please have the definition consistent with definitions in requirement document. Section 2: In the definition of Replicated Media- s/Recordin s/Recording Section 3.1.1 has, "The B2BUA/SRC is responsible for honoring any indication from recording aware UA's or through some configured policies that the communication session must not be recorded." IMO in the current protocol draft there is not a way for the UA to indicate that a session MUST not be recorded. Instead, the UA indicates its preference(a=3Drecordpref attribute), and the SRC MAY "honor" that preference. Are we going to always honor the request from the recording aware UA ?. IMO SRC MUST have flexibility to honor or not depending on its policies. Why do we need section 3.1.3 ? There may be several devices that may not be capable to act as SRC. Is there a reason to explicitly list only proxy ? In Figure 1, show RTCP also in the CS between UA-A and UA-B. Figure 5 shows streams recorded separately for Centralized conferencing case. We can add a note here that we may also have use-cases in centralized conferencing where mixed stream gets recorded to SRS. Update the references to metadata and protocol drafts to have the latest versions. Also add reference to Charles draft (draft-eckel-siprec-rtp-rec). Regards, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Rosen, Brian > Sent: Friday, March 16, 2012 11:04 PM > To: siprec@ietf.org > Subject: [siprec] WGLC on draft-ietf-siprec-architecture >=20 > We would like to start working group last call on -architecture-04. > Normally, we would have a two week WGLC, but since the IETF meeting > falls in the middle, we will extend it to April 6th. >=20 > Please review the draft, even if you have looked at it before. Please > send comments to the list as soon as possible. >=20 > Brian >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From leon.portman@gmail.com Tue Mar 27 04:33:29 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D7B21F899C for ; Tue, 27 Mar 2012 04:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVZt4QpIA8ZM for ; Tue, 27 Mar 2012 04:33:28 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3C021F89AA for ; Tue, 27 Mar 2012 04:33:25 -0700 (PDT) Received: by eeke51 with SMTP id e51so1823568eek.31 for ; Tue, 27 Mar 2012 04:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=k6143uvozpA7s3Mjeh+UYBFkvzHYl29GT0i7/HxUzvo=; b=aW7045JgcVWC6DDOex2j6ZN6kL4ri2UlRufHS0Iisi/238RVZbLjZyRoeZw816Ax23 E9lt6rBTC71Lj15NW/OJsxwmFOzuftR9EnsJ/rWIU+q5N6bsdShufimitqIBETz2VZ2G nosPreQULzPOJ2xDwzI4dTopRW6RSpu7GfbgDBpU4qr4LjTL5eCLb6gWxpKyXvJhAy2L 7kpSsC0GGVRG+aH7xl2Q1OxGRodBaEwDHiO8kNdAz8/hAAIyaUK5olcpiJNUKWRmWO/7 2acsg2KAPF8K0/lT2BUkbkxbj5ogWsee23JOAzCbhYBuc/jhpDcy/RVykkLd2hmF0YVl r7Mw== Received: by 10.213.16.130 with SMTP id o2mr1816690eba.191.1332848004518; Tue, 27 Mar 2012 04:33:24 -0700 (PDT) Received: from ?IPv6:2001:df8::80:20cb:7be2:a202:8176? ([2001:df8:0:80:20cb:7be2:a202:8176]) by mx.google.com with ESMTPS id e56sm68601292eea.11.2012.03.27.04.33.23 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 04:33:23 -0700 (PDT) References: <35BCE99A477D6A4986FB2216D8CF2CFD0A1492D6@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD0A1492D6@XMB-BGL-417.cisco.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B176) From: Leon Portman Date: Tue, 27 Mar 2012 13:33:20 +0200 To: "Ram Mohan R (rmohanr)" Cc: "" Subject: Re: [siprec] WGLC on draft-ietf-siprec-architecture X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 11:33:29 -0000 Ram, Hi Thank you very much for the comments. Regarding honoring recording preferenc= es, this document is an architecture draft that describes possible flows. Th= e actual protocol bits and behaviors are described in the protocol draft. I d= on't feel very comfortable stating in IETF draft that user preferences not b= e recorded can be overridden by policies. Regards Leon On Mar 26, 2012, at 12:14 PM, "Ram Mohan R (rmohanr)" wr= ote: > Leon et al, >=20 > Here are my comments. The document is pretty good shape and most of the > comments are minor ones. >=20 > s/Media Recording Metadata /Recording Metadata at all places in the > document. >=20 > We have not used Media Recording Metadata anywhere in the metadata > draft. I think we can have consistent naming across documents wherever > possible. >=20 > The definitions of SRC, SRS, CS in section 2 is all repetition of what > is already there in RFC 6341. Can we remove them ? In case you still > want to retain them please have the definition consistent with > definitions in requirement document. >=20 > Section 2: In the definition of Replicated Media- > s/Recordin s/Recording >=20 >=20 > Section 3.1.1 has, > "The B2BUA/SRC is responsible for honoring any indication from recording > aware UA's or through some configured policies that the communication > session must not be recorded." > IMO in the current protocol draft there is not a way for the UA to > indicate that a session MUST not be recorded. Instead, the UA indicates > its preference(a=3Drecordpref attribute), and the SRC MAY "honor" that > preference. Are we going to always honor the request from the recording > aware UA ?. IMO SRC MUST have flexibility to honor or not depending on > its policies. >=20 > Why do we need section 3.1.3 ? There may be several devices that may not > be capable to act as SRC. Is there a reason to explicitly list only > proxy ? >=20 > In Figure 1, show RTCP also in the CS between UA-A and UA-B. >=20 >=20 > Figure 5 shows streams recorded separately for Centralized conferencing > case. We can add a note here that we may also have use-cases in > centralized conferencing where mixed stream gets recorded to SRS. >=20 > Update the references to metadata and protocol drafts to have the latest > versions. > Also add reference to Charles draft (draft-eckel-siprec-rtp-rec). >=20 > Regards, > Ram >=20 >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Rosen, Brian >> Sent: Friday, March 16, 2012 11:04 PM >> To: siprec@ietf.org >> Subject: [siprec] WGLC on draft-ietf-siprec-architecture >>=20 >> We would like to start working group last call on -architecture-04. >> Normally, we would have a two week WGLC, but since the IETF meeting >> falls in the middle, we will extend it to April 6th. >>=20 >> Please review the draft, even if you have looked at it before. Please >> send comments to the list as soon as possible. >>=20 >> Brian >>=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 From rmohanr@cisco.com Tue Mar 27 06:55:17 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D7721E81E3 for ; Tue, 27 Mar 2012 06:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.689 X-Spam-Level: X-Spam-Status: No, score=-9.689 tagged_above=-999 required=5 tests=[AWL=0.910, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zw+bLlSMF0k for ; Tue, 27 Mar 2012 06:55:16 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 03E7E21E81CE for ; Tue, 27 Mar 2012 06:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=3833; q=dns/txt; s=iport; t=1332856515; x=1334066115; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=BLieK7VVyRsxkVgIWrbnBqS5zyAwvEGe/Y6qtF25NI4=; b=Ge41pv1wWz1oc6+77WNkx++gCrsz2xwYcF45SDjF4J5KmGfVg0qYgQ/B HjsDykZVJTl1wwLGwI77fSZ1+9OEe1e6tLmm2nNPlK5MSgqAbZrLRGOGW ZBuaM4KT5NNALP1ppTQex6s1cSIA+GbdeSdj75FDZeWafcAiv12+SaS8q M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAKHFcU9Io8UY/2dsb2JhbABFuUiCCQEBAQMBAQEBDwEdCjQLDAQCAQgRAQMBAQEKBhcBBgEgBh8DBggBAQQLCAgah2MFC5sBnw8EiXGGO2MEiFaYPIMUgWiCbw X-IronPort-AV: E=Sophos;i="4.73,657,1325462400"; d="scan'208";a="8721033" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 27 Mar 2012 13:55:13 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2RDtCTi002090; Tue, 27 Mar 2012 13:55:13 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, 27 Mar 2012 19:25:12 +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, 27 Mar 2012 19:25:08 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD0A1497B1@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] WGLC on draft-ietf-siprec-architecture Thread-Index: Ac0MDXWRgrrNndzURu+gdXHPdk1pJwAE3G7Q References: <35BCE99A477D6A4986FB2216D8CF2CFD0A1492D6@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Leon Portman" X-OriginalArrivalTime: 27 Mar 2012 13:55:12.0548 (UTC) FILETIME=[3AE9FE40:01CD0C21] Cc: siprec@ietf.org Subject: Re: [siprec] WGLC on draft-ietf-siprec-architecture X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 13:55:17 -0000 Leon, > -----Original Message----- > From: Leon Portman [mailto:leon.portman@gmail.com] > Sent: Tuesday, March 27, 2012 5:03 PM > To: Ram Mohan R (rmohanr) > Cc: > Subject: Re: [siprec] WGLC on draft-ietf-siprec-architecture >=20 > Ram, Hi >=20 > Thank you very much for the comments. Regarding honoring recording > preferences, this document is an architecture draft that describes > possible flows. The actual protocol bits and behaviors are described in > the protocol draft. I don't feel very comfortable stating in IETF draft > that user preferences not be recorded can be overridden by policies. Ok. Fine with me. Thanks, Ram >=20 > Regards >=20 > Leon >=20 >=20 >=20 > On Mar 26, 2012, at 12:14 PM, "Ram Mohan R (rmohanr)" > wrote: >=20 > > Leon et al, > > > > Here are my comments. The document is pretty good shape and most of > the > > comments are minor ones. > > > > s/Media Recording Metadata /Recording Metadata at all places in the > > document. > > > > We have not used Media Recording Metadata anywhere in the metadata > > draft. I think we can have consistent naming across documents > wherever > > possible. > > > > The definitions of SRC, SRS, CS in section 2 is all repetition of > what > > is already there in RFC 6341. Can we remove them ? In case you still > > want to retain them please have the definition consistent with > > definitions in requirement document. > > > > Section 2: In the definition of Replicated Media- > > s/Recordin s/Recording > > > > > > Section 3.1.1 has, > > "The B2BUA/SRC is responsible for honoring any indication from > recording > > aware UA's or through some configured policies that the communication > > session must not be recorded." > > IMO in the current protocol draft there is not a way for the UA to > > indicate that a session MUST not be recorded. Instead, the UA > indicates > > its preference(a=3Drecordpref attribute), and the SRC MAY "honor" = that > > preference. Are we going to always honor the request from the > recording > > aware UA ?. IMO SRC MUST have flexibility to honor or not depending > on > > its policies. > > > > Why do we need section 3.1.3 ? There may be several devices that may > not > > be capable to act as SRC. Is there a reason to explicitly list only > > proxy ? > > > > In Figure 1, show RTCP also in the CS between UA-A and UA-B. > > > > > > Figure 5 shows streams recorded separately for Centralized > conferencing > > case. We can add a note here that we may also have use-cases in > > centralized conferencing where mixed stream gets recorded to SRS. > > > > Update the references to metadata and protocol drafts to have the > latest > > versions. > > Also add reference to Charles draft (draft-eckel-siprec-rtp-rec). > > > > Regards, > > Ram > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Rosen, Brian > >> Sent: Friday, March 16, 2012 11:04 PM > >> To: siprec@ietf.org > >> Subject: [siprec] WGLC on draft-ietf-siprec-architecture > >> > >> We would like to start working group last call on -architecture-04. > >> Normally, we would have a two week WGLC, but since the IETF meeting > >> falls in the middle, we will extend it to April 6th. > >> > >> Please review the draft, even if you have looked at it before. > Please > >> send comments to the list as soon as possible. > >> > >> Brian > >> > >> _______________________________________________ > >> 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 Mar 28 03:24:52 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE8B21F8950 for ; Wed, 28 Mar 2012 03:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXCZcG6+lW5P for ; Wed, 28 Mar 2012 03:24:49 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id A4EBD21F891C for ; Wed, 28 Mar 2012 03:24:49 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 1C3161EB845B for ; Wed, 28 Mar 2012 12:24:48 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 28 Mar 2012 12:24:48 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" Date: Wed, 28 Mar 2012 12:24:46 +0200 Thread-Topic: IETF83 Meeting Slides. Thread-Index: Ac0MzP+2W9yI4kucS/a/tD5+lczUeA== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31296BC7068@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] IETF83 Meeting Slides. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 10:24:52 -0000 Hi All, All the presentations for the SIPREC meeting on Friday have now been upload= ed. See https://datatracker.ietf.org/meeting/83/materials.html. I hope these are the final slides but I will notify the list if there any u= pdates. Regards Andy From Henry.Lum@genesyslab.com Wed Mar 28 06:53:30 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644F521F895D for ; Wed, 28 Mar 2012 06:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWjibIl35jqD for ; Wed, 28 Mar 2012 06:53:29 -0700 (PDT) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id CEC2321F8819 for ; Wed, 28 Mar 2012 06:53:29 -0700 (PDT) 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 q2SDrSam006001; Wed, 28 Mar 2012 06:53:28 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Mar 2012 06:53:28 -0700 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, 28 Mar 2012 06:53:27 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF740806749F@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on draft-ietf-siprec-protocol-03 Thread-Index: Ac0J4SMaV3862oY6QV++gVxZ3BGhBgDBAqo/ References: From: "Henry Lum" To: "Charles Eckel (eckelcu)" , X-OriginalArrivalTime: 28 Mar 2012 13:53:28.0240 (UTC) FILETIME=[27279B00:01CD0CEA] Subject: Re: [siprec] comments on draft-ietf-siprec-protocol-03 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 13:53:30 -0000 -----Original Message----- From: siprec-bounces@ietf.org on behalf of Charles Eckel (eckelcu) Sent: Sat 3/24/2012 1:11 PM To: siprec@ietf.org Subject: [siprec] comments on draft-ietf-siprec-protocol-03 =20 Section 4.1, fifth paragraph describes an SRC using a single RS to record multiple CSs. However, it some places it uses "calls" instead of "CS". I think these should be changed to "CS". [hlum] Right, I'll make this change: s/call/CS Section 4.2 reads, "Subsequent metadata updates can be represented as a stream of events in INVITE and UPDATE requests". Here and elsewhere in this section, I suggest avoiding this use of "stream". Perhaps replace with, "Subsequent metadata updates can be communicated in subsequent INVITE or UPDATE requests." Also, last sentence, change SRS to SRC. [hlum] Thanks for catching this. Figure 3: Delivering metadata via SIP UDPATE. The initial metadata deliver is via INVITE. Perhaps label simply as "Delivering metadata". [hlum] Agreed. Section 5.1 and 5.2, we do not use the From/To to identify the SRS/SRC. We use feature tags. The use of the feature tag +sip.src and +sip.src mean the SRC/SRS is capable of acting as an SRC/SRS, not that it is in this call. Perhaps use Accept-Contact: *;require;+sip.src or Accept-Contact: *;require;+sip.srs to indicate that the answerer must act as an SRC/SRS? [hlum] Originally what I want to mention is that the From/To identifies = the SRC/SRS which is not the participants in the CS. The participants = are identified in the metadata and we want to make sure that the SRC/SRS = don't use From/To in the recording session to identify the participants. = Perhaps this needs a bit of word-smithing to separate from the use of = the feature tags. Figure 4, second video m-line is labeled as audio. [hlum] thanks for catching this. It should read: m=3Dvideo 22458 RTP/AVP 98 Section 8.1, I find the description of the partial update sending scenarios by the SRC to be very confusion. Isn't if sufficient to say that snapshot requires SDP and partial may not? [hlum] A snapshot actually requires SDP offer in an INVITE/UPDATE = request, while partial does not require SDP and can be in a response. = Perhaps we can simplify the wording a little bit: "A partial update represents an incremental update since the last metadata update sent by the SRC. A partial update sent by the SRC can be an INVITE or UPDATE request or = response containing a "recording-session" disposition, with or without SDP." Section 10.2.1, definition of paused,=20 s/progress by media/progress but media The last sentence read, "This attribute is also not used as an indication to negotiate which SRC in the call path will perform recording and is not used as a request to start/stop recording if there are multiple SRCs in the call path." I suggest replacing with, "This attribute is not used to negotiate which SRC in the call path will perform recording." [hlum] Okay this is simpler. Section 11.2.1 and 11.2.2 Is the appropriate value really "boolean"? Also, I think have the SRC include the +sip.src in INVITEs for CSs being useful to indicate to UAs that the call can be recorded. [hlum] It's a boolean to note whether the the UA is a SRC/SRS or not, = just like +sip.isfocus which is also a boolean as well. Section 11.3, why is this needed? [hlum] It's for SRC or SRS to provide declare content that applies to = recording session only; specifically it is the metadata and metadata = snapshot request. Section 11.4.1, should "rs-metadata" be "rs-metadata+xml" instead? [hlum] Yes that needs to be fixed. Cheers, Charles =20 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From john.2.stafford@bt.com Wed Mar 28 07:48:41 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24AE021E826C for ; Wed, 28 Mar 2012 07:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.989 X-Spam-Level: X-Spam-Status: No, score=-2.989 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnt8g0+V0iD9 for ; Wed, 28 Mar 2012 07:48:40 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 59A8221E8255 for ; Wed, 28 Mar 2012 07:48:39 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 28 Mar 2012 15:48:38 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.101]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Wed, 28 Mar 2012 15:48:37 +0100 From: To: Date: Wed, 28 Mar 2012 15:48:37 +0100 Thread-Topic: Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. Thread-Index: AQHNDPHbKGqRGqQpE0uaR07g0+NKrw== Message-ID: 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: multipart/alternative; boundary="_000_BBA98B7742309546A60F3AE3B4E975A7288801FC4FEMV64UKRDdoma_" MIME-Version: 1.0 Subject: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 14:48:41 -0000 --_000_BBA98B7742309546A60F3AE3B4E975A7288801FC4FEMV64UKRDdoma_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This is as follow up to the threads =93How to specify in metadata that multiple CS's are being recorded in a= single mixed RS m line stream=94 http://www.ietf.org/mail-archive/web/siprec/current/msg03126.html =93How to specify in metadata that a participants stream is being record= ed in multiple m line streams=94 http://www.ietf.org/mail-archive/web/siprec/current/msg03107.html Siprec support for mixed stream recording: I propose multiple streams would use the same label, indicating that the streams are recorded in the same recording m-line st= ream. Siprec support for recording same CS stream in multiple m line streams of 1= RS: This is the converse of the above, I propose that multiple labels be all= owed in a stream element, the meaning would be that the stream is recorded in all of the reference= d recording m-line streams. Implications for existing metadata specification: This does not change the existing metadata usage of streams and labels, = it just adds more flexibility. The only changes required would be that 1. stream=92s label element maxoccurs=3D=941=94 restriction would ne= ed to be removed 2. there would be a 1:n stream:label relationship not 1:1. I can=92t see anything in draft-ietf-siprec-metadata-06 that says = there is a 1:1 relationship anyway. Examples: Mixed Stream Recording: If we have a persistent RS with a single m-line, and a single CS bein= g recorded via a mixed TX/RX stream, then the metadata will have a single element, which has a lab= el referencing a RS m-line. Now if we add a 2nd CS to that RS, we will now have two elem= ents, one for each CS. If they are both being mixed onto the one RS m-line stream, both elements will have the same label, ie: Duplicate Stream Recording If we have a persistent RS with a single m-line, and a single CS bein= g recorded via a mixed TX/RX stream, then the metadata will have a single element, which has a la= bel referencing a RS m-line. If we have a a persistent RS with a two m-line=92s for duplicated rec= ording, then the metadata will have a single element, which has a two lab= els referencing both the RS m-lines. Finally, we could have both the above scenarios together, where the mixe= d two CS recording is duplicated: So why do I think siprec should support these changes ? Requirements for mixed stream recording: RFC6341 refers to mixed recording in use cases 3 and 11 and in REQ 9:= : In Use Case 3: In some cases, more than one concurrent Communication Session (on a single end-user apparatus, e.g., trading-floor turret) is mixed into one Recording Session: |-------- CS 1 -------| |-------- CS 2 -------| |-------- CS 3 -------| RS |----------- Recording Session --------------| t---> In Use case 11: In trading-floor environments, in order to minimize storage and recording system resources, it may be preferable to mix multiple concurrent calls (Communication Sessions) on different handsets/ speakers on the same turret into a single recording session. REQ-009: The mechanism MUST support the ability for an SRC to deliver mixed audio streams from different parties of a given Communication Session to an SRS. To me this implies multiple CS=92s in one mixed recorder stream, sinc= e the requirement specifically says =94mix=94, and =94to minimise storage=94. Requirements for Duplicated stream recording: RFC6341 does not specifically mention duplicated recording But I don=92t think allowing it would complicate the metadata, and it= will be down to the recorder implementation how it handles the duplicated CS recording. Rgds John Stafford | Solution Architect 1 | BT Global Services --_000_BBA98B7742309546A60F3AE3B4E975A7288801FC4FEMV64UKRDdoma_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

This is as follow up to the threads
   =93How to specify in metadata that multiple CS's are being rec= orded in a single mixed RS m line stream=94
   http://www.ietf.org/mail-archive/web/siprec/current/msg0312= 6.html

   =93How to specify in metadata that a participants stream is be= ing recorded in multiple m line streams=94
    http://www.ietf.org/mail-archive/web/siprec/current/m= sg03107.html
 

Siprec support for mixed stream recording:
   I propose multiple streams would use the same label,
   indicating that the streams = are recorded in the same recording m-line stream.
 
Siprec support for recording same CS stream in multiple m line streams of 1= RS:
   This is the converse of the above, I propose that multiple lab= els be allowed in a  stream element,
   the meaning would be that the stream is recorded in all of the= referenced recording m-line streams.
 

Implications for existing metadata specificat= ion:
   This does not change the existing metadata usage of streams an= d labels, it just adds more flexibility.
   The only changes required would be that 
      1. stream=92s label element  maxoccurs= =3D=941=94 restriction would need to be removed
      2. there would  be a 1:n stream:label r= elationship not 1:1.
         I can=92t see anything in = draft-ietf-siprec-metadata-06 that says there is a 1:1 relationship anyway.=
 
 
 
 
Examples:
   Mixed Stream Recording:
      If we have a persistent RS with a single m-l= ine, and a single CS being recorded via a mixed TX/RX stream,
     then the metadata will have a single <stream>= ; element, which has a label referencing a RS m-line.
 
      Now if we add a 2nd CS to that RS, we will n= ow have two <Stream> elements, one for each CS.
      If they are both being mixed onto the one RS= m-line stream, both <stream> elements will have the same label, ie:<= br>   
      <stream id=3D"Axzg12XHdhjelfjhdldjf;= 34jn78=3D=3D"
            &nb= sp;       session=3D"zzlafnvvjlCHllaHF6m= n8kkSS=3D=3D=94>
            &nb= sp;       <label>99</label>
            &nb= sp;   </stream>
      <stream id=3D"EiXGlc+4TruqqoDaNE= 76ag=3D=3D"
            &nb= sp;       session=3D"zSfPoSvdSDCmU3A3TRD= xAw=3D=3D">
            &nb= sp;       <label>99</label>
            &nb= sp;   </stream>
 
 
 
 
   Duplicate Stream Recording
      If we have a persistent RS with a single m-l= ine, and a single CS being recorded via a mixed TX/RX stream,
      then the metadata will have a single <str= eam> element, which has a label referencing a RS m-line.
 
      If we have a a persistent RS with a two m-li= ne=92s for duplicated recording, then
      the metadata will have a single <stream&g= t; element, which has a two labels referencing both the RS m-lines.
 
     <stream id=3D"Axzg12XHdhjelfjhdldjf;34jn78= =3D=3D"
            &nb= sp;       session=3D"zzlafnvvjlCHllaHF6m= n8kkSS=3D=3D=94>
            &nb= sp;       <label>99</label>
            &nb= sp;       <label>100</label>
            &nb= sp;   </stream>
 


   Finally, we could have both the above scenarios together, wher= e the mixed two CS recording is duplicated:
 
      <stream id=3D"Axzg12XHdhjelfjhdldjf;= 34jn78=3D=3D"
            &nb= sp;       session=3D"zzlafnvvjlCHllaHF6m= n8kkSS=3D=3D=94>
            &nb= sp;       <label>99</label>
            &nb= sp;       <label>100</label>
            &nb= sp;   </stream>
      <stream id=3D"EiXGlc+4TruqqoDaNE= 76ag=3D=3D"
            &nb= sp;       session=3D"zSfPoSvdSDCmU3A3TRD= xAw=3D=3D">
            &nb= sp;      <label>99</label>
            &nb= sp;       <label>100</label>
            &nb= sp;   </stream>
 

 

 


 
So why do I think siprec should support these changes ? 
 
 
   Requirements for mixed stream recording:
 
      RFC6341 refers to mixed recording in use cas= es 3 and 11 and in REQ 9::
 
      In Use Case 3:
         In some cases, more than o= ne concurrent Communication Session (on
         a single end-user apparatu= s, e.g., trading-floor turret) is mixed
         into one Recording Session= :
 
            &nb= sp;            = |-------- CS 1 -------|
            &nb= sp;            =     |-------- CS 2 -------|
            &nb= sp;           |-------- C= S 3 -------|
 
            RS = |----------- Recording Session --------------|
            t--->=
 
      In Use case 11:
         In trading-floor environme= nts, in order to minimize storage and
         recording system resources= , it may be preferable to mix multiple
         concurrent calls (Communic= ation Sessions) on different handsets/
         speakers on the same turre= t into a single recording session.
 
      REQ-009: The mechanism MUST support the abil= ity for an SRC to
         deliver mixed audio stream= s from different parties of a given
         Communication Session to a= n SRS.
 
 
      To me this implies multiple CS=92s in one mi= xed recorder stream, since the requirement specifically

   &= nbsp;  says =94mix=94, and =94to minimise storage=94.
 
 
 
   Requirements for Duplicated stream recording:
      RFC6341 does not specifically mention duplic= ated recording
      But I don=92t think allowing it would compli= cate the metadata, and it will be down to the recorder

   &nb= sp;  implementation how it handles the duplicated CS recording.=
 
 

 

Rgds

John Stafford |&= nbsp;Solution Architect 1 | BT Global Services

--_000_BBA98B7742309546A60F3AE3B4E975A7288801FC4FEMV64UKRDdoma_-- From pravindran@sonusnet.com Wed Mar 28 14:42:30 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D903221F8562 for ; Wed, 28 Mar 2012 14:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.904 X-Spam-Level: X-Spam-Status: No, score=-4.904 tagged_above=-999 required=5 tests=[AWL=1.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHWERDYGUFXb for ; Wed, 28 Mar 2012 14:42:27 -0700 (PDT) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with ESMTP id A1E2E21F8534 for ; Wed, 28 Mar 2012 14:42:26 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKT3OFwXVCiI9mdv4nRL27OBVF9rgBDyLL@postini.com; Wed, 28 Mar 2012 14:42:26 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 28 Mar 2012 17:42:44 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Thu, 29 Mar 2012 03:12:20 +0530 From: "Ravindran, Parthasarathi" To: "john.2.stafford@bt.com" , "siprec@ietf.org" Thread-Topic: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. Thread-Index: AQHNDPHbKGqRGqQpE0uaR07g0+NKr5aANujQ Date: Wed, 28 Mar 2012 21:42:40 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E221327@inba-mail01.sonusnet.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C0E221327inbamail01sonus_" MIME-Version: 1.0 Subject: Re: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 21:42:31 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C0E221327inbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable John, I'll explain how to form metadata XML element for your requirement: "Siprec support for recording same CS stream in multiple m line streams of = 1 RS: This is the converse of the above, I propose that multiple labels be all= owed in a stream element, the meaning would be that the stream is recorded in all of the reference= d recording m-line streams." Here, There are two CS's, 2 m'line and 1 RS. For representing as per curr= ent XML schema is as follows, Could you please explain the issue in the above approach. Thanks Partha From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= john.2.stafford@bt.com Sent: Wednesday, March 28, 2012 8:19 PM To: siprec@ietf.org Subject: [siprec] Proposal for minor changes to metadata to support mixed s= tream and duplicated stream recording. This is as follow up to the threads "How to specify in metadata that multiple CS's are being recorded in a s= ingle mixed RS m line stream" http://www.ietf.org/mail-archive/web/siprec/current/msg03126.html "How to specify in metadata that a participants stream is being recorded= in multiple m line streams" http://www.ietf.org/mail-archive/web/siprec/current/msg03107.html Siprec support for mixed stream recording: I propose multiple streams would use the same label, indicating that the streams are recorded in the same recording m-line st= ream. Siprec support for recording same CS stream in multiple m line streams of 1= RS: This is the converse of the above, I propose that multiple labels be all= owed in a stream element, the meaning would be that the stream is recorded in all of the reference= d recording m-line streams. Implications for existing metadata specification: This does not change the existing metadata usage of streams and labels, = it just adds more flexibility. The only changes required would be that 1. stream's label element maxoccurs=3D"1" restriction would need to = be removed 2. there would be a 1:n stream:label relationship not 1:1. I can't see anything in draft-ietf-siprec-metadata-06 that says th= ere is a 1:1 relationship anyway. Examples: Mixed Stream Recording: If we have a persistent RS with a single m-line, and a single CS bein= g recorded via a mixed TX/RX stream, then the metadata will have a single element, which has a lab= el referencing a RS m-line. Now if we add a 2nd CS to that RS, we will now have two elem= ents, one for each CS. If they are both being mixed onto the one RS m-line stream, both elements will have the same label, ie: Duplicate Stream Recording If we have a persistent RS with a single m-line, and a single CS bein= g recorded via a mixed TX/RX stream, then the metadata will have a single element, which has a la= bel referencing a RS m-line. If we have a a persistent RS with a two m-line's for duplicated recor= ding, then the metadata will have a single element, which has a two lab= els referencing both the RS m-lines. Finally, we could have both the above scenarios together, where the mixe= d two CS recording is duplicated: So why do I think siprec should support these changes ? Requirements for mixed stream recording: RFC6341 refers to mixed recording in use cases 3 and 11 and in REQ 9:= : In Use Case 3: In some cases, more than one concurrent Communication Session (on a single end-user apparatus, e.g., trading-floor turret) is mixed into one Recording Session: |-------- CS 1 -------| |-------- CS 2 -------| |-------- CS 3 -------| RS |----------- Recording Session --------------| t---> In Use case 11: In trading-floor environments, in order to minimize storage and recording system resources, it may be preferable to mix multiple concurrent calls (Communication Sessions) on different handsets/ speakers on the same turret into a single recording session. REQ-009: The mechanism MUST support the ability for an SRC to deliver mixed audio streams from different parties of a given Communication Session to an SRS. To me this implies multiple CS's in one mixed recorder stream, since = the requirement specifically says "mix", and "to minimise storage". Requirements for Duplicated stream recording: RFC6341 does not specifically mention duplicated recording But I don't think allowing it would complicate the metadata, and it w= ill be down to the recorder implementation how it handles the duplicated CS recording. Rgds John Stafford | Solution Architect 1 | BT Global Services --_000_387F9047F55E8C42850AD6B3A7A03C6C0E221327inbamail01sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

John,

 <= /p>

I’ll explain how to= form metadata XML element for your requirement:

 <= /p>

“Siprec= support for recording same CS stream in multiple m line streams of 1 RS:    This is the converse of the above, I propose that multiple lab= els be allowed in a  stream element,
   the meaning would be that the stream is recorded in all of the= referenced recording m-line streams.”

 

Here,  T= here are two CS’s,  2 m’line and 1 RS. For representing as= per current XML schema is as follows,

 

  &= nbsp;   <stream id=3D"Axzg12XHdhjelfjhdldjf;34jn78=3D=3D&= quot;
            &nb= sp;       session=3D"zzlafnvvjlCHllaHF6m= n8kkSS=3D=3D”>
            &nb= sp;       <label>99</label>
       </stream>

  &= nbsp;   <stream id=3D"Axzg12XHdhjelfjhdldjf;34jn78=3D=3D&= quot;
            &nb= sp;       session=3D" zSfPoSvdSDCmU3A3TR= DxAw=3D=3D”>
            &nb= sp;       <label>99</label>
       </stream>
      <stream id=3D"EiXGlc+4TruqqoDaNE= 76ag=3D=3D"
            &nb= sp;       session=3D" zzlafnvvjlCHllaHF6= mn8kkSS=3D=3D">
            &nb= sp;       <label>100</label>
       </stream>

  &= nbsp;   <stream id=3D"EiXGlc+4TruqqoDaNE76ag=3D=3D&qu= ot;
            &nb= sp;       session=3D"zSfPoSvdSDCmU3A3TRD= xAw=3D=3D">
            &nb= sp;      <label>99</label>
       </stream>

 <= /p>

Could you please explain = the issue in the above approach.

 <= /p>

Thanks<= /p>

Partha<= /p>

 <= /p>

From: siprec-b= ounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of john.2.stafford@bt.com
Sent: Wednesday, March 28, 2012 8:19 PM
To: siprec@ietf.org
Subject: [siprec] Proposal for minor changes to metadata to support = mixed stream and duplicated stream recording.

 


This is as follow up to the threads
   “How to specify in metadata that multiple CS's are being= recorded in a single mixed RS m line stream”
   http://www.ietf.org/mail-archive/web/siprec/current/msg0312= 6.html


   “How to specify in metadata that a participants stream i= s being recorded in multiple m line streams”
    http://www.ietf.org/mail-archive/web/siprec/current/m= sg03107.html
 


Siprec support for mixed stream recording:
   I propose multiple streams would use the same label,

   = indicating that the streams are recorded in the same recording m-line strea= m.
 
Siprec support for recording same CS stream in multiple m line streams of 1= RS:
   This is the converse of the above, I propose that multiple lab= els be allowed in a  stream element,
   the meaning would be that the stream is recorded in all of the= referenced recording m-line streams.
 

Implications = for existing metadata specification:
   This does not change the existing metadata usage of streams an= d labels, it just adds more flexibility.
   The only changes required would be that 
      1. stream’s label element  maxocc= urs=3D”1” restriction would need to be removed
      2. there would  be a 1:n stream:label r= elationship not 1:1.
         I can’t see anything= in draft-ietf-siprec-metadata-06 that says there is a 1:1 relationship any= way.
 
 
 
 
Examples:
   Mixed Stream Recording:
      If we have a persistent RS with a single m-l= ine, and a single CS being recorded via a mixed TX/RX stream,
     then the metadata will have a single <stream>= ; element, which has a label referencing a RS m-line.
 
      Now if we add a 2nd CS to that RS, we will n= ow have two <Stream> elements, one for each CS.
      If they are both being mixed onto the one RS= m-line stream, both <stream> elements will have the same label, ie:<= br>   
      <stream id=3D"Axzg12XHdhjelfjhdldjf;= 34jn78=3D=3D"
            &nb= sp;       session=3D"zzlafnvvjlCHllaHF6m= n8kkSS=3D=3D”>
            &nb= sp;       <label>99</label>
            &nb= sp;   </stream>
      <stream id=3D"EiXGlc+4TruqqoDaNE= 76ag=3D=3D"
            &nb= sp;       session=3D"zSfPoSvdSDCmU3A3TRD= xAw=3D=3D">
            &nb= sp;       <label>99</label>
            &nb= sp;   </stream>
 
 
 
 
   Duplicate Stream Recording
      If we have a persistent RS with a single m-l= ine, and a single CS being recorded via a mixed TX/RX stream,
      then the metadata will have a single <str= eam> element, which has a label referencing a RS m-line.
 
      If we have a a persistent RS with a two m-li= ne’s for duplicated recording, then
      the metadata will have a single <stream&g= t; element, which has a two labels referencing both the RS m-lines.
 
     <stream id=3D"Axzg12XHdhjelfjhdldjf;34jn78= =3D=3D"
            &nb= sp;       session=3D"zzlafnvvjlCHllaHF6m= n8kkSS=3D=3D”>
            &nb= sp;       <label>99</label>
            &nb= sp;       <label>100</label>
            &nb= sp;   </stream>
 <= /p>


   Finally, we could have both the above scenarios together, wher= e the mixed two CS recording is duplicated:
 
      <stream id=3D"Axzg12XHdhjelfjhdldjf;= 34jn78=3D=3D"
            &nb= sp;       session=3D"zzlafnvvjlCHllaHF6m= n8kkSS=3D=3D”>
            &nb= sp;       <label>99</label>
            &nb= sp;       <label>100</label>
            &nb= sp;   </stream>
      <stream id=3D"EiXGlc+4TruqqoDaNE= 76ag=3D=3D"
            &nb= sp;       session=3D"zSfPoSvdSDCmU3A3TRD= xAw=3D=3D">
            &nb= sp;      <label>99</label>
            &nb= sp;       <label>100</label>
            &nb= sp;   </stream>
 <= /p>

 

 


 
So why do I think siprec should support these changes ? 
 
 
   Requirements for mixed stream recording:
 
      RFC6341 refers to mixed recording in use cas= es 3 and 11 and in REQ 9::
 
      In Use Case 3:
         In some cases, more than o= ne concurrent Communication Session (on
         a single end-user apparatu= s, e.g., trading-floor turret) is mixed
         into one Recording Session= :
 
            &nb= sp;            = |-------- CS 1 -------|
            &nb= sp;            =     |-------- CS 2 -------|
            &nb= sp;           |-------- C= S 3 -------|
 
            RS = |----------- Recording Session --------------|
            t--->=
 
      In Use case 11:
         In trading-floor environme= nts, in order to minimize storage and
         recording system resources= , it may be preferable to mix multiple
         concurrent calls (Communic= ation Sessions) on different handsets/
         speakers on the same turre= t into a single recording session.
 
      REQ-009: The mechanism MUST support the abil= ity for an SRC to
         deliver mixed audio stream= s from different parties of a given
         Communication Session to a= n SRS.
 
 
      To me this implies multiple CS’s in on= e mixed recorder stream, since the requirement specifically

  &= nbsp;   says ”mix”, a= nd ”to minimise storage”.
 
 
 
   Requirements for Duplicated stream recording:
      RFC6341 does not specifically mention duplic= ated recording
      But I don’t think allowing it would co= mplicate the metadata, and it will be down to the recorder

 &nb= sp;    implementation how it handles the duplicated CS recor= ding.
 
 

 

Rgds<= /span>

John Stafford | Solution Architect 1 | BT Global Se= rvices

--_000_387F9047F55E8C42850AD6B3A7A03C6C0E221327inbamail01sonus_-- From john.2.stafford@bt.com Thu Mar 29 02:07:28 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0CA21F85F6 for ; Thu, 29 Mar 2012 02:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qsp8uAtAkbPQ for ; Thu, 29 Mar 2012 02:07:26 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 6796821F85A4 for ; Thu, 29 Mar 2012 02:07:25 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 29 Mar 2012 10:07:24 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.101]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Thu, 29 Mar 2012 10:07:23 +0100 From: To: , Date: Thu, 29 Mar 2012 10:04:31 +0100 Thread-Topic: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. Thread-Index: AQHNDPHbKGqRGqQpE0uaR07g0+NKr5aANujQgADFHNI= Message-ID: References: , <387F9047F55E8C42850AD6B3A7A03C6C0E221327@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E221327@inba-mail01.sonusnet.com> 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: multipart/alternative; boundary="_000_BBA98B7742309546A60F3AE3B4E975A7288801FC51EMV64UKRDdoma_" MIME-Version: 1.0 Subject: Re: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 09:07:28 -0000 --_000_BBA98B7742309546A60F3AE3B4E975A7288801FC51EMV64UKRDdoma_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Partha, so you are saying there is no need to allow multiple labels on a stream e= lement, as a stream elemet can be repeated in the metadata multiple times. I dont see how this matches the object model, a element with a unique id = can surely on occur once in the matadata. Rgds John Stafford | Solution Architect 1 | BT Global Services | Tel:+44 (0)1932= 773504 | E: john.2.stafford@bt.com | ww= w.bt.com/globalservices ________________________________ From: Ravindran, Parthasarathi [pravindran@sonusnet.com] Sent: 28 March 2012 22:42 To: Stafford,J,John,JRJ3X C; siprec@ietf.org Subject: RE: [siprec] Proposal for minor changes to metadata to support mix= ed stream and duplicated stream recording. John, I=92ll explain how to form metadata XML element for your requirement: =93Siprec support for recording same CS stream in multiple m line streams o= f 1 RS: This is the converse of the above, I propose that multiple labels be all= owed in a stream element, the meaning would be that the stream is recorded in all of the reference= d recording m-line streams.=94 Here, There are two CS=92s, 2 m=92line and 1 RS. For representing as per = current XML schema is as follows, Could you please explain the issue in the above approach. Thanks Partha From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= john.2.stafford@bt.com Sent: Wednesday, March 28, 2012 8:19 PM To: siprec@ietf.org Subject: [siprec] Proposal for minor changes to metadata to support mixed s= tream and duplicated stream recording. This is as follow up to the threads =93How to specify in metadata that multiple CS's are being recorded in a= single mixed RS m line stream=94 http://www.ietf.org/mail-archive/web/siprec/current/msg03126.html =93How to specify in metadata that a participants stream is being record= ed in multiple m line streams=94 http://www.ietf.org/mail-archive/web/siprec/current/msg03107.html Siprec support for mixed stream recording: I propose multiple streams would use the same label, indicating that the streams are recorded in the same recording m-line st= ream. Siprec support for recording same CS stream in multiple m line streams of 1= RS: This is the converse of the above, I propose that multiple labels be all= owed in a stream element, the meaning would be that the stream is recorded in all of the reference= d recording m-line streams. Implications for existing metadata specification: This does not change the existing metadata usage of streams and labels, = it just adds more flexibility. The only changes required would be that 1. stream=92s label element maxoccurs=3D=941=94 restriction would ne= ed to be removed 2. there would be a 1:n stream:label relationship not 1:1. I can=92t see anything in draft-ietf-siprec-metadata-06 that says = there is a 1:1 relationship anyway. Examples: Mixed Stream Recording: If we have a persistent RS with a single m-line, and a single CS bein= g recorded via a mixed TX/RX stream, then the metadata will have a single element, which has a lab= el referencing a RS m-line. Now if we add a 2nd CS to that RS, we will now have two elem= ents, one for each CS. If they are both being mixed onto the one RS m-line stream, both elements will have the same label, ie: Duplicate Stream Recording If we have a persistent RS with a single m-line, and a single CS bein= g recorded via a mixed TX/RX stream, then the metadata will have a single element, which has a la= bel referencing a RS m-line. If we have a a persistent RS with a two m-line=92s for duplicated rec= ording, then the metadata will have a single element, which has a two lab= els referencing both the RS m-lines. Finally, we could have both the above scenarios together, where the mixe= d two CS recording is duplicated: So why do I think siprec should support these changes ? Requirements for mixed stream recording: RFC6341 refers to mixed recording in use cases 3 and 11 and in REQ 9:= : In Use Case 3: In some cases, more than one concurrent Communication Session (on a single end-user apparatus, e.g., trading-floor turret) is mixed into one Recording Session: |-------- CS 1 -------| |-------- CS 2 -------| |-------- CS 3 -------| RS |----------- Recording Session --------------| t---> In Use case 11: In trading-floor environments, in order to minimize storage and recording system resources, it may be preferable to mix multiple concurrent calls (Communication Sessions) on different handsets/ speakers on the same turret into a single recording session. REQ-009: The mechanism MUST support the ability for an SRC to deliver mixed audio streams from different parties of a given Communication Session to an SRS. To me this implies multiple CS=92s in one mixed recorder stream, sinc= e the requirement specifically says =94mix=94, and =94to minimise storage=94. Requirements for Duplicated stream recording: RFC6341 does not specifically mention duplicated recording But I don=92t think allowing it would complicate the metadata, and it= will be down to the recorder implementation how it handles the duplicated CS recording. Rgds John Stafford | Solution Architect 1 | BT Global Services --_000_BBA98B7742309546A60F3AE3B4E975A7288801FC51EMV64UKRDdoma_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Partha,
 
  so you are saying there is no need to all= ow multiple labels on a stream element, as a stream elemet can be repeated = in the metadata multiple times.
 
  I dont see how this matches the object mo= del, a element with a unique id can surely on occur once in the matadata.
 
 
Rgds
John Stafford | Solution Architect 1 | BT Global = Services | Tel:+44 (0)1932 773504   | E: john.2.stafford@bt.co= m  |  www.bt.com/globals= ervices=
 
=  
From: Ravindran, = Parthasarathi [pravindran@sonusnet.com]
Sent: 28 March 2012 22:42
To: Stafford,J,John,JRJ3X C; siprec@ietf.org
Subject: RE: [siprec] Proposal for minor changes to metadata to supp= ort mixed stream and duplicated stream recording.

John,

 

I=92ll explain how to form metadata XML el= ement for your requirement:

 

=93Siprec support for recordin= g same CS stream in multiple m line streams of 1 RS:
   This is the converse of the above, I propose that multiple lab= els be allowed in a  stream element,
   the meaning would be that the stream is recorded in all of the= referenced recording m-line streams.=94

 

Here,  There are two CS= =92s,  2 m=92line and 1 RS. For representing as per current XML schema= is as follows,

 

     = <stream id=3D"Axzg12XHdhjelfjhdldjf;34jn78=3D=3D"
            &nb= sp;       session=3D"zzlafnvvjlCHllaHF6m= n8kkSS=3D=3D=94>
            &nb= sp;       <label>99</label>
       </stream>

     = <stream id=3D"Axzg12XHdhjelfjhdldjf;34jn78=3D=3D"
            &nb= sp;       session=3D" zSfPoSvdSDCmU3A3TR= DxAw=3D=3D=94>
            &nb= sp;       <label>99</label>
       </stream>
      <stream id=3D"EiXGlc+4TruqqoDaNE= 76ag=3D=3D"
            &nb= sp;       session=3D" zzlafnvvjlCHllaHF6= mn8kkSS=3D=3D">
            &nb= sp;       <label>100</label>
       </stream>

     = <stream id=3D"EiXGlc+4TruqqoDaNE76ag=3D=3D"
            &nb= sp;       session=3D"zSfPoSvdSDCmU3A3TRD= xAw=3D=3D">
            &nb= sp;      <label>99</label>
       </stream>

 

Could you please explain the issue in the = above approach.

 

Thanks

Partha

 

From: siprec-bounces@ietf.org [mailto:siprec-bounces= @ietf.org] On Behalf Of john.2.stafford@bt.com
Sent: Wednesday, March 28, 2012 8:19 PM
To: siprec@ietf.org
Subject: [siprec] Proposal for minor changes to metadata to support = mixed stream and duplicated stream recording.

 


This is as follow up to the threads
   =93How to specify in metadata that multiple CS's are being rec= orded in a single mixed RS m line stream=94
   http://www.ietf.org/mail-archive/web/sipr= ec/current/msg03126.html


   =93How to specify in metadata that a participants stream is be= ing recorded in multiple m line streams=94
    http://www.ietf.org/mail-archive/web/siprec/current/msg03107.html
 


Siprec support for mixed stream recording:
   I propose multiple streams would use the same label,

   indicating that t= he streams are recorded in the same recording m-line stream.
 
Siprec support for recording same CS stream in multiple m line streams of 1= RS:
   This is the converse of the above, I propose that multiple lab= els be allowed in a  stream element,
   the meaning would be that the stream is recorded in all of the= referenced recording m-line streams.
 

Implications for existing meta= data specification:
   This does not change the existing metadata usage of streams an= d labels, it just adds more flexibility.
   The only changes required would be that 
      1. stream=92s label element  maxoccurs= =3D=941=94 restriction would need to be removed
      2. there would  be a 1:n stream:label r= elationship not 1:1.
         I can=92t see anything in = draft-ietf-siprec-metadata-06 that says there is a 1:1 relationship anyway.=
 
 
 
 
Examples:
   Mixed Stream Recording:
      If we have a persistent RS with a single m-l= ine, and a single CS being recorded via a mixed TX/RX stream,
     then the metadata will have a single <stream>= ; element, which has a label referencing a RS m-line.
 
      Now if we add a 2nd CS to that RS, we will n= ow have two <Stream> elements, one for each CS.
      If they are both being mixed onto the one RS= m-line stream, both <stream> elements will have the same label, ie:<= br>   
      <stream id=3D"Axzg12XHdhjelfjhdldjf;= 34jn78=3D=3D"
            &nb= sp;       session=3D"zzlafnvvjlCHllaHF6m= n8kkSS=3D=3D=94>
            &nb= sp;       <label>99</label>
            &nb= sp;   </stream>
      <stream id=3D"EiXGlc+4TruqqoDaNE= 76ag=3D=3D"
            &nb= sp;       session=3D"zSfPoSvdSDCmU3A3TRD= xAw=3D=3D">
            &nb= sp;       <label>99</label>
            &nb= sp;   </stream>
 
 
 
 
   Duplicate Stream Recording
      If we have a persistent RS with a single m-l= ine, and a single CS being recorded via a mixed TX/RX stream,
      then the metadata will have a single <str= eam> element, which has a label referencing a RS m-line.
 
      If we have a a persistent RS with a two m-li= ne=92s for duplicated recording, then
      the metadata will have a single <stream&g= t; element, which has a two labels referencing both the RS m-lines.
 
     <stream id=3D"Axzg12XHdhjelfjhdldjf;34jn78= =3D=3D"
            &nb= sp;       session=3D"zzlafnvvjlCHllaHF6m= n8kkSS=3D=3D=94>
            &nb= sp;       <label>99</label>
            &nb= sp;       <label>100</label>
            &nb= sp;   </stream>
 


   Finally, we could have both the above scenarios together, wher= e the mixed two CS recording is duplicated:
 
      <stream id=3D"Axzg12XHdhjelfjhdldjf;= 34jn78=3D=3D"
            &nb= sp;       session=3D"zzlafnvvjlCHllaHF6m= n8kkSS=3D=3D=94>
            &nb= sp;       <label>99</label>
            &nb= sp;       <label>100</label>
            &nb= sp;   </stream>
      <stream id=3D"EiXGlc+4TruqqoDaNE= 76ag=3D=3D"
            &nb= sp;       session=3D"zSfPoSvdSDCmU3A3TRD= xAw=3D=3D">
            &nb= sp;      <label>99</label>
            &nb= sp;       <label>100</label>
            &nb= sp;   </stream>
 

&= nbsp;

&= nbsp;


 
So why do I think siprec should support these changes ? 
 
 
   Requirements for mixed stream recording:
 
      RFC6341 refers to mixed recording in use cas= es 3 and 11 and in REQ 9::
 
      In Use Case 3:
         In some cases, more than o= ne concurrent Communication Session (on
         a single end-user apparatu= s, e.g., trading-floor turret) is mixed
         into one Recording Session= :
 
            &nb= sp;            = |-------- CS 1 -------|
            &nb= sp;            =     |-------- CS 2 -------|
            &nb= sp;           |-------- C= S 3 -------|
 
            RS = |----------- Recording Session --------------|
            t--->=
 
      In Use case 11:
         In trading-floor environme= nts, in order to minimize storage and
         recording system resources= , it may be preferable to mix multiple
         concurrent calls (Communic= ation Sessions) on different handsets/
         speakers on the same turre= t into a single recording session.
 
      REQ-009: The mechanism MUST support the abil= ity for an SRC to
         deliver mixed audio stream= s from different parties of a given
         Communication Session to a= n SRS.
 
 
      To me this implies multiple CS=92s in one mi= xed recorder stream, since the requirement specifically

      says =94mix=94, and =94t= o minimise storage=94.
 
 
 
   Requirements for Duplicated stream recording:
      RFC6341 does not specifically mention duplic= ated recording
      But I don=92t think allowing it would compli= cate the metadata, and it will be down to the recorder

 &n= bsp;    implementation how it handles the duplicated CS reco= rding.
 
 

&= nbsp;

Rgds

John S= tafford | Solution Architect 1 | BT Global Services

--_000_BBA98B7742309546A60F3AE3B4E975A7288801FC51EMV64UKRDdoma_-- From pkyzivat@alum.mit.edu Thu Mar 29 05:09:15 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFA521F8A48 for ; Thu, 29 Mar 2012 05:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.528 X-Spam-Level: X-Spam-Status: No, score=-1.528 tagged_above=-999 required=5 tests=[AWL=-0.521, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYALARJWCYGM for ; Thu, 29 Mar 2012 05:09:14 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id A169021F8A5B for ; Thu, 29 Mar 2012 05:09:11 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta13.westchester.pa.mail.comcast.net with comcast id rQ8h1i0020vyq2s5DQ962s; Thu, 29 Mar 2012 12:09:06 +0000 Received: from dhcp-16f3.meeting.ietf.org ([130.129.22.243]) by omta05.westchester.pa.mail.comcast.net with comcast id rQ8x1i00P5EhBnE3RQ8ztv; Thu, 29 Mar 2012 12:09:04 +0000 Message-ID: <4F7383AC.6020405@alum.mit.edu> Date: Wed, 28 Mar 2012 23:33:32 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: siprec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 12:09:15 -0000 On 3/28/12 4:48 PM, john.2.stafford@bt.com wrote: > > This is as follow up to the threads > “How to specify in metadata that multiple CS's are being recorded in a > single mixed RS m line stream” > http://www.ietf.org/mail-archive/web/siprec/current/msg03126.html > > “How to specify in metadata that a participants stream is being recorded > in multiple m line streams” > http://www.ietf.org/mail-archive/web/siprec/current/msg03107.html > > Siprec support for mixed stream recording: > I propose multiple streams would use the same label, > indicating that the streams are recorded in the same recording m-line > stream. Unless these streams are somehow independently separable by the SRS, it seems to me that they are functionally equivalent to a single CS with multiple participants. Or, are the separate because the parties in one of the calls can't hear the people in the other call? Without some sense of what this means (in terms of how the multiple streams have been combined) this could be incomprehensible to the SRS. > Siprec support for recording same CS stream in multiple m line streams > of 1 RS: > This is the converse of the above, I propose that multiple labels be > allowed in a stream element, > the meaning would be that the stream is recorded in all of the > referenced recording m-line streams. I am having difficulty understanding why that would be a useful thing to do. Can you explain? Is is for redundancy? It isn't *very* redundant - neither the source nor the destination of the streams is duplicated. I guess you can get *something* if the two streams are on different subnets. We had envisioned accomplishing redundancy by establishing independent RS sessions to two different SRSs. But allowing what you request seems innocuous enough. But do you then expect us to provide guidance to the SRS implementer about what to do when this usage occurs? > Implications for existing metadata specification: > This does not change the existing metadata usage of streams and labels, > it just adds more flexibility. > The only changes required would be that > 1. stream’s label element maxoccurs=”1” restriction would need to be removed > 2. there would be a 1:n stream:label relationship not 1:1. > I can’t see anything in draft-ietf-siprec-metadata-06 that says there is > a 1:1 relationship anyway. > > > > > Examples: > Mixed Stream Recording: > If we have a persistent RS with a single m-line, and a single CS being > recorded via a mixed TX/RX stream, > then the metadata will have a single element, which has a label > referencing a RS m-line. > > Now if we add a 2nd CS to that RS, we will now have two > elements, one for each CS. > If they are both being mixed onto the one RS m-line stream, both > elements will have the same label, ie: I suppose you have some idea of how these will be combined into the single RTP session represented by the m-line. But there are a lot of possibilities, and its not clear if/how they are reversible. (Reversible only by human ears is perhaps one way, though probably not the best.) > session="zzlafnvvjlCHllaHF6mn8kkSS==”> > > > session="zSfPoSvdSDCmU3A3TRDxAw=="> > > > > > > > Duplicate Stream Recording > If we have a persistent RS with a single m-line, and a single CS being > recorded via a mixed TX/RX stream, > then the metadata will have a single element, which has a label > referencing a RS m-line. > > If we have a a persistent RS with a two m-line’s for duplicated > recording, then > the metadata will have a single element, which has a two labels > referencing both the RS m-lines. > > session="zzlafnvvjlCHllaHF6mn8kkSS==”> > > > See my redundancy comment above. > Finally, we could have both the above scenarios together, where the > mixed two CS recording is duplicated: > > session="zzlafnvvjlCHllaHF6mn8kkSS==”> > > > > session="zSfPoSvdSDCmU3A3TRDxAw=="> > > > > > > > So why do I think siprec should support these changes ? > > > Requirements for mixed stream recording: > > RFC6341 refers to mixed recording in use cases 3 and 11 and in REQ 9:: > > In Use Case 3: > In some cases, more than one concurrent Communication Session (on > a single end-user apparatus, e.g., trading-floor turret) is mixed > into one Recording Session: > > |-------- CS 1 -------| > |-------- CS 2 -------| > |-------- CS 3 -------| > > RS |----------- Recording Session --------------| > t---> > > In Use case 11: > In trading-floor environments, in order to minimize storage and > recording system resources, it may be preferable to mix multiple > concurrent calls (Communication Sessions) on different handsets/ > speakers on the same turret into a single recording session. > > REQ-009: The mechanism MUST support the ability for an SRC to > deliver mixed audio streams from different parties of a given > Communication Session to an SRS. I guess we clearly support 9 now, and probably not 3 and 11. Recording of the mix of multiple independent calls could certainly result in recording mostly noise. Maybe not so bad if you are sending the different calls as separate RPT streams (distinct SSRCs), especially if there were some way to associate the individual RTP streams to the siprec streams. > To me this implies multiple CS’s in one mixed recorder stream, since the > requirement specifically > > says ”mix”, and ”to minimise storage”. > > > > Requirements for Duplicated stream recording: > RFC6341 does not specifically mention duplicated recording > But I don’t think allowing it would complicate the metadata, and it will > be down to the recorder > > implementation how it handles the duplicated CS recording. As I noted above, we did consider duplicated recording, and assumed you would achieve it via separate recording sessions. Thanks, Paul From eckelcu@cisco.com Thu Mar 29 10:26:09 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1CA21F8799 for ; Thu, 29 Mar 2012 10:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.223 X-Spam-Level: X-Spam-Status: No, score=-9.223 tagged_above=-999 required=5 tests=[AWL=0.776, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id or-aHfpVlDWf for ; Thu, 29 Mar 2012 10:26:08 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id F2B6E21F8787 for ; Thu, 29 Mar 2012 10:26:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=4771; q=dns/txt; s=iport; t=1333041968; x=1334251568; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=zSGK9BVW3BiEfb3VwNyJEzSLRbpe3wc8ZRom4JiKWl4=; b=Y9vC0ZGUatbpGava6Y5gIDezLIT9NOb64x6nm96EikbJoLs0FMlM1d8O pJ1uVHcxltqLjnq+1tPICLU4BOpt2I+VCmXTvrwF4w3T60WbxZgMXJ7PV k+gCTU8WTbJ6giABU05eeiR0dj5/Q08wNCjOl5NzffEvMFRG7j8JbgQEU 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOOZdE+rRDoI/2dsb2JhbAA7CrkTgQeCCQEBAQMBAQEBDwEdCjQQBwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHYwQBC5wPnysEinOFSWMEiFibT4Fogwc X-IronPort-AV: E=Sophos;i="4.75,669,1330905600"; d="scan'208";a="35661483" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 29 Mar 2012 17:26:07 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2THQ7Me005491; Thu, 29 Mar 2012 17:26:07 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); Thu, 29 Mar 2012 10:26:07 -0700 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, 29 Mar 2012 10:26:05 -0700 Message-ID: In-Reply-To: <059AF07365DC474393A19A3AF187DF740806749F@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] comments on draft-ietf-siprec-protocol-03 Thread-Index: Ac0J4SMaV3862oY6QV++gVxZ3BGhBgDBAqo/ADqIHyA= References: <059AF07365DC474393A19A3AF187DF740806749F@NAHALD.us.int.genesyslab.com> From: "Charles Eckel (eckelcu)" To: "Henry Lum" , X-OriginalArrivalTime: 29 Mar 2012 17:26:07.0469 (UTC) FILETIME=[06A931D0:01CD0DD1] Subject: Re: [siprec] comments on draft-ietf-siprec-protocol-03 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 17:26:09 -0000 > -----Original Message----- > From: Henry Lum [mailto:Henry.Lum@genesyslab.com] > Sent: Wednesday, March 28, 2012 3:53 PM > To: Charles Eckel (eckelcu); siprec@ietf.org > Subject: RE: [siprec] comments on draft-ietf-siprec-protocol-03 >=20 >=20 >=20 >=20 > -----Original Message----- > From: siprec-bounces@ietf.org on behalf of Charles Eckel (eckelcu) > Sent: Sat 3/24/2012 1:11 PM > To: siprec@ietf.org > Subject: [siprec] comments on draft-ietf-siprec-protocol-03 >=20 > Section 4.1, fifth paragraph describes an SRC using a single RS to > record multiple CSs. However, it some places it uses "calls" instead of > "CS". I think these should be changed to "CS". >=20 > [hlum] Right, I'll make this change: s/call/CS >=20 > Section 4.2 reads, "Subsequent metadata updates can be represented as a > stream of events in INVITE and UPDATE requests". Here and elsewhere in > this section, I suggest avoiding this use of "stream". Perhaps replace > with, "Subsequent metadata updates can be communicated in subsequent > INVITE or UPDATE requests." > Also, last sentence, change SRS to SRC. >=20 > [hlum] Thanks for catching this. >=20 > Figure 3: Delivering metadata via SIP UDPATE. > The initial metadata deliver is via INVITE. Perhaps label simply as > "Delivering metadata". >=20 > [hlum] Agreed. >=20 > Section 5.1 and 5.2, we do not use the From/To to identify the SRS/SRC. > We use feature tags. The use of the feature tag +sip.src and +sip.src > mean the SRC/SRS is capable of acting as an SRC/SRS, not that it is in > this call. Perhaps use Accept-Contact: *;require;+sip.src or > Accept-Contact: *;require;+sip.srs to indicate that the answerer must > act as an SRC/SRS? >=20 > [hlum] Originally what I want to mention is that the From/To identifies > the SRC/SRS which is not the participants in the CS. The participants > are identified in the metadata and we want to make sure that the > SRC/SRS don't use From/To in the recording session to identify the > participants. Perhaps this needs a bit of word-smithing to separate > from the use of the feature tags. I see. I agree that To/From should not be used to identify participants. That may be worth mentioning. That said, To/From should not be used as SRS/SRC identifiers either. I agree with separating from feature tags. My Accept-Contact comment should be applied the existing feature tag section instead. > Figure 4, second video m-line is labeled as audio. >=20 > [hlum] thanks for catching this. It should read: > m=3Dvideo 22458 RTP/AVP 98 >=20 >=20 > Section 8.1, I find the description of the partial update sending > scenarios by the SRC to be very confusion. Isn't if sufficient to say > that snapshot requires SDP and partial may not? >=20 > [hlum] A snapshot actually requires SDP offer in an INVITE/UPDATE > request, while partial does not require SDP and can be in a response. > Perhaps we can simplify the wording a little bit: >=20 > "A partial update represents an > incremental update since the last metadata update sent by the SRC. > A > partial update sent by the SRC can be an INVITE or UPDATE request or > response containing > a "recording-session" disposition, with or without SDP." I can live with that. > Section 10.2.1, definition of paused, > s/progress by media/progress but media >=20 > The last sentence read, "This attribute is also not used as an > indication to negotiate which SRC in the call path will perform > recording and is not used as a request to start/stop recording if there > are multiple SRCs in the call path." > I suggest replacing with, "This attribute is not used to negotiate > which > SRC in the call path will perform recording." >=20 > [hlum] Okay this is simpler. >=20 > Section 11.2.1 and 11.2.2 > Is the appropriate value really "boolean"? > Also, I think have the SRC include the +sip.src in INVITEs for CSs > being > useful to indicate to UAs that the call can be recorded. >=20 > [hlum] It's a boolean to note whether the the UA is a SRC/SRS or not, > just like +sip.isfocus which is also a boolean as well. Okay. > Section 11.3, why is this needed? >=20 > [hlum] It's for SRC or SRS to provide declare content that applies to > recording session only; specifically it is the metadata and metadata > snapshot request. Okay. I still don't understand it completely, but will take your word on it. Cheers, Charles >=20 > Section 11.4.1, should "rs-metadata" be "rs-metadata+xml" instead? >=20 > [hlum] Yes that needs to be fixed. >=20 > Cheers, > Charles >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From john.2.stafford@bt.com Thu Mar 29 10:35:48 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC6F21E819E for ; Thu, 29 Mar 2012 10:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.968 X-Spam-Level: X-Spam-Status: No, score=-2.968 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-TA66n+67ml for ; Thu, 29 Mar 2012 10:35:47 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id A029521E8180 for ; Thu, 29 Mar 2012 10:35:46 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 29 Mar 2012 18:35:45 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.101]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Thu, 29 Mar 2012 18:35:45 +0100 From: To: , Date: Thu, 29 Mar 2012 18:35:45 +0100 Thread-Topic: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. Thread-Index: Ac0NpN1m6Z8kGGWqS3GBLENwb11tdAALAwTr Message-ID: References: , <4F7383AC.6020405@alum.mit.edu> In-Reply-To: <4F7383AC.6020405@alum.mit.edu> 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: multipart/alternative; boundary="_000_BBA98B7742309546A60F3AE3B4E975A7288801FC5CEMV64UKRDdoma_" MIME-Version: 1.0 Subject: Re: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 17:35:48 -0000 --_000_BBA98B7742309546A60F3AE3B4E975A7288801FC5CEMV64UKRDdoma_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Paul, comments inline, JS Rgds John Stafford | Solution Architect 1 | BT Global Services _________________= _______________________ From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of Paul K= yzivat [pkyzivat@alum.mit.edu] Sent: 28 March 2012 22:33 To: siprec@ietf.org Subject: Re: [siprec] Proposal for minor changes to metadata to support mix= ed stream and duplicated stream recording. On 3/28/12 4:48 PM, john.2.stafford@bt.com wrote: > > This is as follow up to the threads > =93How to specify in metadata that multiple CS's are being recorded in a > single mixed RS m line stream=94 > http://www.ietf.org/mail-archive/web/siprec/current/msg03126.html > > =93How to specify in metadata that a participants stream is being recorde= d > in multiple m line streams=94 > http://www.ietf.org/mail-archive/web/siprec/current/msg03107.html > > Siprec support for mixed stream recording: > I propose multiple streams would use the same label, > indicating that the streams are recorded in the same recording m-line > stream. Unless these streams are somehow independently separable by the SRS, it seems to me that they are functionally equivalent to a single CS with multiple participants. Or, are the separate because the parties in one of the calls can't hear the people in the other call? JS: Yes thats it, the calls are completely separate so far as the participa= nts are concerned. Without some sense of what this means (in terms of how the multiple streams have been combined) this could be incomprehensible to the SRS. JS: A simple audio mix was what we intended. > Siprec support for recording same CS stream in multiple m line streams > of 1 RS: > This is the converse of the above, I propose that multiple labels be > allowed in a stream element, > the meaning would be that the stream is recorded in all of the > referenced recording m-line streams. I am having difficulty understanding why that would be a useful thing to do. Can you explain? Is is for redundancy? It isn't *very* redundant - neither the source nor the destination of the streams is duplicated. I guess you can get *something* if the two streams are on different subnets. We had envisioned accomplishing redundancy by establishing independent RS sessions to two different SRSs. JS: The destination of the streams could be different if the recorder assig= ned streams to different loggers. But allowing what you request seems innocuous enough. But do you then expect us to provide guidance to the SRS implementer about what to do when this usage occurs? JS: I think it can be left to the SRS implmented, there I are I think two m= ain choices record one stream and ignore the other, or record both and provide facility in search to replay iether recordin= g of the CS. > Implications for existing metadata specification: > This does not change the existing metadata usage of streams and labels, > it just adds more flexibility. > The only changes required would be that > 1. stream=92s label element maxoccurs=3D=941=94 restriction would need to= be removed > 2. there would be a 1:n stream:label relationship not 1:1. > I can=92t see anything in draft-ietf-siprec-metadata-06 that says there i= s > a 1:1 relationship anyway. > > > > > Examples: > Mixed Stream Recording: > If we have a persistent RS with a single m-line, and a single CS being > recorded via a mixed TX/RX stream, > then the metadata will have a single element, which has a label > referencing a RS m-line. > > Now if we add a 2nd CS to that RS, we will now have two > elements, one for each CS. > If they are both being mixed onto the one RS m-line stream, both > elements will have the same label, ie: I suppose you have some idea of how these will be combined into the single RTP session represented by the m-line. But there are a lot of possibilities, and its not clear if/how they are reversible. (Reversible only by human ears is perhaps one way, though probably not the best.) JS: I had only envisaged the reversible only by human ears possibility, can= you explain the other possibilities. > session=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D=94> > > > session=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> > > > > > > > Duplicate Stream Recording > If we have a persistent RS with a single m-line, and a single CS being > recorded via a mixed TX/RX stream, > then the metadata will have a single element, which has a label > referencing a RS m-line. > > If we have a a persistent RS with a two m-line=92s for duplicated > recording, then > the metadata will have a single element, which has a two labels > referencing both the RS m-lines. > > session=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D=94> > > > See my redundancy comment above. > Finally, we could have both the above scenarios together, where the > mixed two CS recording is duplicated: > > session=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D=94> > > > > session=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> > > > > > > > So why do I think siprec should support these changes ? > > > Requirements for mixed stream recording: > > RFC6341 refers to mixed recording in use cases 3 and 11 and in REQ 9:: > > In Use Case 3: > In some cases, more than one concurrent Communication Session (on > a single end-user apparatus, e.g., trading-floor turret) is mixed > into one Recording Session: > > |-------- CS 1 -------| > |-------- CS 2 -------| > |-------- CS 3 -------| > > RS |----------- Recording Session --------------| > t---> > > In Use case 11: > In trading-floor environments, in order to minimize storage and > recording system resources, it may be preferable to mix multiple > concurrent calls (Communication Sessions) on different handsets/ > speakers on the same turret into a single recording session. > > REQ-009: The mechanism MUST support the ability for an SRC to > deliver mixed audio streams from different parties of a given > Communication Session to an SRS. I guess we clearly support 9 now, and probably not 3 and 11. Recording of the mix of multiple independent calls could certainly result in recording mostly noise. Maybe not so bad if you are sending the different calls as separate RPT streams (distinct SSRCs), especially if there were some way to associate the individual RTP streams to the siprec streams. > To me this implies multiple CS=92s in one mixed recorder stream, since th= e > requirement specifically > > says =94mix=94, and =94to minimise storage=94. > > > > Requirements for Duplicated stream recording: > RFC6341 does not specifically mention duplicated recording > But I don=92t think allowing it would complicate the metadata, and it wil= l > be down to the recorder > > implementation how it handles the duplicated CS recording. As I noted above, we did consider duplicated recording, and assumed you would achieve it via separate recording sessions. Thanks, Paul _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec --_000_BBA98B7742309546A60F3AE3B4E975A7288801FC5CEMV64UKRDdoma_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Paul,

comments inline, JS

Rgds
John Stafford | Solution Architect 1 | BT Global Services _________________= _______________________
From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of Paul K= yzivat [pkyzivat@alum.mit.edu]
Sent: 28 March 2012 22:33
To: siprec@ietf.org
Subject: Re: [siprec] Proposal for minor changes to metadata to support mix= ed stream and duplicated stream recording.

On 3/28/12 4:48 PM, john.2.stafford@bt.com wrote:
>
> This is as follow up to the threads
> =93How to specify in metadata that multiple CS's are being recorded in= a
> single mixed RS m line stream=94
> http://www.ietf.org/mail-archive/web/siprec/current/msg03126.html
>
> =93How to specify in metadata that a participants stream is being reco= rded
> in multiple m line streams=94
> http://www.ietf.org/mail-archive/web/siprec/current/msg03107.html
>
> Siprec support for mixed stream recording:
> I propose multiple streams would use the same label,
> indicating that the streams are recorded in the same recording m-line<= br> > stream.

Unless these streams are somehow independently separable by the SRS, it
seems to me that they are functionally equivalent to a single CS with
multiple participants.

Or, are the separate because the parties in one of the calls can't hear
the people in the other call?

JS: Yes thats it, the calls are completely separate= so far as the participants are concerned.

Without some sense of what this means (in terms of how the multiple<= br> streams have been combined) this could be incomprehensible to the SRS.

JS: A simple audi= o mix was what we intended.

> Siprec support for recording same CS stream in multiple m line streams=
> of 1 RS:
> This is the converse of the above, I propose that multiple labels be > allowed in a stream element,
> the meaning would be that the stream is recorded in all of the
> referenced recording m-line streams.

I am having difficulty understanding why that would be a useful thing to do. Can you explain? Is is for redundancy? It isn't *very* redundant -
neither the source nor the destination of the streams is duplicated. I
guess you can get *something* if the two streams are on different
subnets. We had envisioned accomplishing redundancy by establishing
independent RS sessions to two different SRSs.

JS: The destination of = the streams could be different if the recorder assigned streams to differen= t loggers.

 


But allowing what you request seems innocuous enough. But do you then
expect us to provide guidance to the SRS implementer about what to do
when this usage occurs?

JS: I think it can be l= eft to the SRS implmented, there I are I think two main choices

    record one stream and ignore the other,

    or record both and provide facility in search to replay iether recording of= the CS.

> Implications for existing metadata specification:
> This does not change the existing metadata usage of streams and labels= ,
> it just adds more flexibility.
> The only changes required would be that
> 1. stream=92s label element maxoccurs=3D=941=94 restriction would need= to be removed
> 2. there would be a 1:n stream:label relationship not 1:1.
> I can=92t see anything in draft-ietf-siprec-metadata-06 that says ther= e is
> a 1:1 relationship anyway.
>
>
>
>
> Examples:
> Mixed Stream Recording:
> If we have a persistent RS with a single m-line, and a single CS being=
> recorded via a mixed TX/RX stream,
> then the metadata will have a single <stream> element, which has= a label
> referencing a RS m-line.
>
> Now if we add a 2nd CS to that RS, we will now have two <Stream>=
> elements, one for each CS.
> If they are both being mixed onto the one RS m-line stream, both
> <stream> elements will have the same label, ie:

I suppose you have some idea of how these will be combined into the
single RTP session represented by the m-line. But there are a lot of
possibilities, and its not clear if/how they are reversible. (Reversible only by human ears is perhaps one way, though probably not the best.)

JS: I had only envisage= d the reversible only by human ears possibility, can you explain the other = possibilities.

 


> <stream id=3D"Axzg12XHdhjelfjhdldjf;34jn78=3D=3D"
> session=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D=94>
> <label>99</label>
> </stream>
> <stream id=3D"EiXGlc+4TruqqoDaNE76ag=3D=3D"
> session=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D">
> <label>99</label>
> </stream>
>
>
>
>
> Duplicate Stream Recording
> If we have a persistent RS with a single m-line, and a single CS being=
> recorded via a mixed TX/RX stream,
> then the metadata will have a single <stream> element, which has= a label
> referencing a RS m-line.
>
> If we have a a persistent RS with a two m-line=92s for duplicated
> recording, then
> the metadata will have a single <stream> element, which has a tw= o labels
> referencing both the RS m-lines.
>
> <stream id=3D"Axzg12XHdhjelfjhdldjf;34jn78=3D=3D"
> session=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D=94>
> <label>99</label>
> <label>100</label>
> </stream>

See my redundancy comment above.

> Finally, we could have both the above scenarios together, where the > mixed two CS recording is duplicated:
>
> <stream id=3D"Axzg12XHdhjelfjhdldjf;34jn78=3D=3D"
> session=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D=94>
> <label>99</label>
> <label>100</label>
> </stream>
> <stream id=3D"EiXGlc+4TruqqoDaNE76ag=3D=3D"
> session=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D">
> <label>99</label>
> <label>100</label>
> </stream>
>
>
>
> So why do I think siprec should support these changes ?
>
>
> Requirements for mixed stream recording:
>
> RFC6341 refers to mixed recording in use cases 3 and 11 and in REQ 9::=
>
> In Use Case 3:
> In some cases, more than one concurrent Communication Session (on
> a single end-user apparatus, e.g., trading-floor turret) is mixed
> into one Recording Session:
>
> |-------- CS 1 -------|
> |-------- CS 2 -------|
> |-------- CS 3 -------|
>
> RS |----------- Recording Session --------------|
> t--->
>
> In Use case 11:
> In trading-floor environments, in order to minimize storage and
> recording system resources, it may be preferable to mix multiple
> concurrent calls (Communication Sessions) on different handsets/
> speakers on the same turret into a single recording session.
>
> REQ-009: The mechanism MUST support the ability for an SRC to
> deliver mixed audio streams from different parties of a given
> Communication Session to an SRS.

I guess we clearly support 9 now, and probably not 3 and 11.

Recording of the mix of multiple independent calls could certainly
result in recording mostly noise. Maybe not so bad if you are sending
the different calls as separate RPT streams (distinct SSRCs), especially if there were some way to associate the individual RTP streams to the
siprec streams.

> To me this implies multiple CS=92s in one mixed recorder stream, since= the
> requirement specifically
>
> says =94mix=94, and =94to minimise storage=94.
>
>
>
> Requirements for Duplicated stream recording:
> RFC6341 does not specifically mention duplicated recording
> But I don=92t think allowing it would complicate the metadata, and it = will
> be down to the recorder
>
> implementation how it handles the duplicated CS recording.

As I noted above, we did consider duplicated recording, and assumed you
would achieve it via separate recording sessions.

        Thanks,
        Paul
_______________________________________________
siprec mailing list
siprec@ietf.org
https://www.ietf.org/mailman/listinfo/siprec

--_000_BBA98B7742309546A60F3AE3B4E975A7288801FC5CEMV64UKRDdoma_-- From ietf@meetecho.com Thu Mar 29 15:50:40 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D5D21E8054 for ; Thu, 29 Mar 2012 15:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWdyx8N8oq+3 for ; Thu, 29 Mar 2012 15:50:39 -0700 (PDT) Received: from smtplq03.aruba.it (smtplqs-out29.aruba.it [62.149.158.69]) by ietfa.amsl.com (Postfix) with SMTP id 53C3E21E802A for ; Thu, 29 Mar 2012 15:50:38 -0700 (PDT) Received: (qmail 29043 invoked by uid 89); 29 Mar 2012 22:50:36 -0000 Received: from unknown (HELO smtp2.aruba.it) (62.149.158.222) by smtplq03.aruba.it with SMTP; 29 Mar 2012 22:50:36 -0000 Received: (qmail 24024 invoked by uid 89); 29 Mar 2012 22:50:36 -0000 Received: from unknown (HELO ?192.168.0.40?) (alex@meetecho.com@78.192.151.119) by smtp2.ad.aruba.it with ESMTPA; 29 Mar 2012 22:50:35 -0000 Message-ID: <4F74E733.90901@meetecho.com> Date: Fri, 30 Mar 2012 00:50:27 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: siprec@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtplq03.aruba.it 1.6.2 0/1000/N Cc: Team Meetecho Subject: [siprec] Meetecho support for SIPREC WG meeting session X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 22:50:40 -0000 Hi all, a virtual room has been reserved on the Meetecho system for Friday's SIPREC WG meeting session. Access to the on-line session (including audio and video streams) will be available at: http://www.meetecho.com/ietf83/siprec The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. Remote participants might also send their own voice to the room, if they want to, by either calling a landline phone number, or using our embedded VoIP applet (in this last case they are *strongly* advised to use a headset). A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf83/tutorials Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From andrew.hutton@siemens-enterprise.com Thu Mar 29 22:37:55 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F2721F87B5 for ; Thu, 29 Mar 2012 22:37:55 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pqk-4yS9oJvf for ; Thu, 29 Mar 2012 22:37:54 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE9321F86C7 for ; Thu, 29 Mar 2012 22:37:54 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 6D2221EB844F for ; Fri, 30 Mar 2012 07:37:52 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 30 Mar 2012 07:37:52 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" Date: Fri, 30 Mar 2012 07:37:49 +0200 Thread-Topic: IETF83 Slides. Thread-Index: Ac0ONz55qNBqcDUyRm+mEs2kjOpr2Q== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31296C4CE62@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] IETF83 Slides. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 05:37:55 -0000 Hi, A minor update to the slides for today's meeting relating to draft-ietf-sip= rec-protocol has been uploaded and can be found at: See https://datatracker.ietf.org/meeting/83/materials.html. I allowed this as it is only a bug fix. Regards Andy From thomas.stach@siemens-enterprise.com Fri Mar 30 02:07:50 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 858F221F8881 for ; Fri, 30 Mar 2012 02:07:50 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SL-U2t-tU4+e for ; Fri, 30 Mar 2012 02:07:49 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 54E8721F887E for ; Fri, 30 Mar 2012 02:07:49 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 14BE823F04B5; Fri, 30 Mar 2012 11:07:48 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 30 Mar 2012 11:07:48 +0200 From: "Stach, Thomas" To: Brian Rosen , "Hutton, Andrew" Date: Fri, 30 Mar 2012 11:07:45 +0200 Thread-Topic: Draft Minutes from SIPREC session Thread-Index: Ac0OVJIj3Y+/CROZQUmsDCAf2sIwAg== Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: [siprec] Draft Minutes from SIPREC session X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 09:07:50 -0000 Brian, Andy, below are my minutes.=20 Please scan through and correct if I got something wrong. Kind Regards Thomas SIPREC WG - IETF 83.=20 0905 - 0910 5 mins Chairs WG Status Upd= ate=20 WGLC closes on April 6th. Comments were solicited =20 0910 - 0925 15 mins Leon Portman = SIPREC Architecture draft http://tools.ietf.org/html/draft= -ietf-siprec-architecture-04 =20 Honoring "Not record" preference of a UA. Editor wants input if this could = be made mandatory? Need for 3.1.3 proposals to either remove or to make clear that the items i= n the draft are not exhaustive. On SRS initiated recording: Wording seems to imply that recording is mandat= ory, text needs clarification 0925 - 0955 30 mins Henry Lum = SIPREC Protocol http://tools.ietf.org/html/draft-ietf-siprec-protocol-= 03 =20 Metadata mandatory to implement? Difficulty to verify this, if no metadata is actually available to be sent.= =20 It was proposed that metadata is to be sent at the time of initial offer/an= swer.=20 It is hard to mandate it for persistent recording. Metadata might not be av= ailable at the time of establishment of recording session, later on e.g. in= snapshot requests it would have to be provided. Text needs to be make the different scenarios as clear as possible. Conclusion: Mandatory to implement, but only mandatory to be sent when avai= lable. Does the draft need to mention the difference in recording a CS that uses S= DES vs. DTLS-SRTP for security? This has no impact on the protocol, but pro= bably needs to be mentioned elsewhere e.g. in RTP model. It was proposed th= e seek advice from security directorate/experts. Richard Barnes volunteered= to do this. =20 0955 - 1020 25 mins Partha Ravindran = SIPREC Metadata http://tools.ietf.org/html/draft-ietf-siprec-metadata-06 =20 Agreement on slides 1-6,=20 Slide 7: Start/Stop time attributes will be added. Slide 8 (BT use case for Trading/Touret system):=20 Recording of several CSs mixed into a single RS. Other example is recording of two way radio.=20 The associated semantics will be documented, update of use cases draft nece= ssary? Further list discussion needs to happen to identify other potential use cas= es and their associated semantics. Due to the involved complexity it was proposed to work on a document showin= g various examples of the whole picture. WGLC premature, wait for outcome of ongoing list discussion. 1020 - 1050 25 mins Charles Eckel = RTP Recommendations for SIPREC http://tools.ietf.org/html= /draft-eckel-siprec-rtp-rec-03 =20 Slide 7: RCTP support proposed to be at SHOULD strength in order to cover e= .g. SIP UA without RTCP support. Slide 8: Providing CNAME/SSRC/CSRC could be useful, but should be kept opti= onal. Slide 9: no objections Slide 10: no decision on whether to include into protcol document or have s= eparate document, took to the list From br@brianrosen.net Fri Mar 30 02:24:23 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98FD321F8830 for ; Fri, 30 Mar 2012 02:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.623 X-Spam-Level: X-Spam-Status: No, score=-102.623 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAv2OUXJA+0R for ; Fri, 30 Mar 2012 02:24:22 -0700 (PDT) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by ietfa.amsl.com (Postfix) with ESMTP id 6383D21F881D for ; Fri, 30 Mar 2012 02:24:22 -0700 (PDT) X-ASG-Debug-ID: 1333099461-04d035034b94190001-sFFYAS Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id F92AC3lwmfH1OjDs; Fri, 30 Mar 2012 02:24:21 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from [209.173.57.233] (helo=[192.168.130.23]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SDY4F-002llx-4Y; Fri, 30 Mar 2012 02:24:23 -0700 Mime-Version: 1.0 (Apple Message framework v1257) X-ASG-Orig-Subj: Re: Draft Minutes from SIPREC session Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: Date: Fri, 30 Mar 2012 05:24:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <852364A7-CC57-4BE1-9E36-F47C37BA48A1@brianrosen.net> References: To: "Stach, Thomas" X-Mailer: Apple Mail (2.1257) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1333099461 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.12 X-Barracuda-Spam-Status: No, SCORE=0.12 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=CN_BODY_332 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.92670 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 Cc: "siprec@ietf.org" Subject: Re: [siprec] Draft Minutes from SIPREC session X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 09:24:23 -0000 Thanks! Great work. Brian On Mar 30, 2012, at 5:07 AM, Stach, Thomas wrote: > Brian, Andy, >=20 > below are my minutes.=20 > Please scan through and correct if I got something wrong. >=20 > Kind Regards > Thomas >=20 >=20 > SIPREC WG - IETF 83.=20 >=20 > 0905 - 0910 5 mins Chairs WG = Status Update=20 >=20 > WGLC closes on April 6th. Comments were solicited >=20 >=20 > 0910 - 0925 15 mins Leon Portman = SIPREC Architecture draft = http://tools.ietf.org/html/draft-ietf-siprec-architecture-04 =20 >=20 > Honoring "Not record" preference of a UA. Editor wants input if this = could be made mandatory? > Need for 3.1.3 proposals to either remove or to make clear that the = items in the draft are not exhaustive. > On SRS initiated recording: Wording seems to imply that recording is = mandatory, text needs clarification >=20 > 0925 - 0955 30 mins Henry Lum = SIPREC Protocol = http://tools.ietf.org/html/draft-ietf-siprec-protocol-03 =20 >=20 > Metadata mandatory to implement? > Difficulty to verify this, if no metadata is actually available to be = sent.=20 > It was proposed that metadata is to be sent at the time of initial = offer/answer.=20 > It is hard to mandate it for persistent recording. Metadata might not = be available at the time of establishment of recording session, later on = e.g. in snapshot requests it would have to be provided. > Text needs to be make the different scenarios as clear as possible. >=20 > Conclusion: Mandatory to implement, but only mandatory to be sent when = available. >=20 > Does the draft need to mention the difference in recording a CS that = uses SDES vs. DTLS-SRTP for security? This has no impact on the = protocol, but probably needs to be mentioned elsewhere e.g. in RTP = model. It was proposed the seek advice from security = directorate/experts. Richard Barnes volunteered to do this. >=20 >=20 > 0955 - 1020 25 mins Partha Ravindran = SIPREC Metadata = http://tools.ietf.org/html/draft-ietf-siprec-metadata-06 =20 >=20 > Agreement on slides 1-6,=20 > Slide 7: Start/Stop time attributes will be added. > Slide 8 (BT use case for Trading/Touret system):=20 > Recording of several CSs mixed into a single RS. > Other example is recording of two way radio.=20 > The associated semantics will be documented, update of use cases draft = necessary? > Further list discussion needs to happen to identify other potential = use cases and their associated semantics. >=20 > Due to the involved complexity it was proposed to work on a document = showing various examples of the whole picture. >=20 > WGLC premature, wait for outcome of ongoing list discussion. >=20 > 1020 - 1050 25 mins Charles Eckel = RTP Recommendations for SIPREC = http://tools.ietf.org/html/draft-eckel-siprec-rtp-rec-03 =20 >=20 > Slide 7: RCTP support proposed to be at SHOULD strength in order to = cover e.g. SIP UA without RTCP support. > Slide 8: Providing CNAME/SSRC/CSRC could be useful, but should be kept = optional. > Slide 9: no objections > Slide 10: no decision on whether to include into protcol document or = have separate document, took to the list >=20 >=20 >=20 >=20