From andrew.hutton@siemens-enterprise.com Mon Jul 2 03:01: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 26C4811E8166 for ; Mon, 2 Jul 2012 03:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 yYyeRIlj7F-7 for ; Mon, 2 Jul 2012 03:01:34 -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 66A3811E812E for ; Mon, 2 Jul 2012 03:01:34 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id BAFF11EB84D1 for ; Mon, 2 Jul 2012 12:01:37 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.34]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.01.0339.001; Mon, 2 Jul 2012 12:01:37 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: SIPREC Session at IETF84 Thread-Index: Ac1YOapY1IJ7VIv5TRqfzgDDvv8CxA== Date: Mon, 2 Jul 2012 10:01:36 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF03377F@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.27.255.61] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] SIPREC Session at IETF84 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, 02 Jul 2012 10:01:35 -0000 Hi All, We have the following session at IETF 84 http://www.ietf.org/meeting/84/ind= ex.html.=20 siprec Session 1 (2:00:00) Thursday, Afternoon Session I 1300-1500 Room Name: Georgia A. We need to work on the agenda over the couple of weeks so please forward ag= enda proposals to the chairs at siprec-chairs@tools.ietf.org.=20 Regards Andy (SIPREC Co-Chair). From pravindran@sonusnet.com Mon Jul 2 22:35: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 9B76421F8718 for ; Mon, 2 Jul 2012 22:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_65=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 88YkuCO8nVqy for ; Mon, 2 Jul 2012 22:35:33 -0700 (PDT) Received: from na3sys010aog103.obsmtp.com (na3sys010aog103.obsmtp.com [74.125.245.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5B47F21F8713 for ; Mon, 2 Jul 2012 22:35:32 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob103.postini.com ([74.125.244.12]) with SMTP ID DSNKT/KEqJpnzbvTyem4rwR3sv+1c2kx4Xis@postini.com; Mon, 02 Jul 2012 22:35:39 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; Tue, 3 Jul 2012 01:36:25 -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, 3 Jul 2012 11:05:30 +0530 From: "Ravindran, Parthasarathi" To: "siprec@ietf.org" Thread-Topic: Duplicate stream recording [was RE: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording.] Thread-Index: AQHNWN2oTgsvTmgOjU+ioX0WLwHsqg== Date: Tue, 3 Jul 2012 05:35:29 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C1605CB19@inba-mail01.sonusnet.com> References: , <4FAC1EDD.8030800@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C16034636@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C16034E25@inba-mail01.sonusnet.com> <9F33F40F6F2CD847824537F3C4E37DDF012140@MCHP04MSX.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C1603732F@inba-mail01.sonusnet.com> <9F33F40F6F2CD847824537F3C4E37DDF012A04@MCHP04MSX.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C160389A1@inba-mail01.sonusnet.com> <9F33F40F6F2CD847824537F3C4E37DDF013E3F@MCHP04MSX.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C160557A2@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C160557A2@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Duplicate stream recording [was RE: 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: Tue, 03 Jul 2012 05:35:35 -0000 Duplicate stream shall be represented in SDP itself. There is a proposal fo= r creating AVTEXT WG milestone for duplicate stream. The same attributes sh= all be used for SIPREC as well. One of the candidate draft proposal for dup= licate stream is http://datatracker.ietf.org/doc/draft-begen-avtcore-rtp-du= plication/. Please let me know in case any issue in adopting duplicate stre= am using SDP mechanism for SIPREC as well. Thanks Partha=20 >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Ravindran, Parthasarathi >Sent: Thursday, June 21, 2012 6:42 AM >To: Hutton, Andrew >Cc: siprec@ietf.org >Subject: Re: [siprec] Proposal for minor changes to metadata to support >mixed stream and duplicated stream recording. > >Hi Andy, > >From SRC perspective, there are two streams towards RS with the same >content and each stream has to have different unique id to differentiate >with stream_id. The stream_id is not directly mapped with individual CS >stream as it is not possible with mixed streams. The related current >text in sec 6.7 of metadata draft is > >"A Media Stream class (and its objects) has the properties of media as >seen by SRC and sent to SRS." > >Please let me know whether the text has to be updated for more clarity. >Also, the open item here is "any attribute is required to indicate that >two stream towards SRS are same" > >Thanks >Partha > >>-----Original Message----- >>From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] >>Sent: Wednesday, May 30, 2012 5:37 PM >>To: Ravindran, Parthasarathi >>Cc: siprec@ietf.org; john.2.stafford@bt.com >>Subject: RE: [siprec] Proposal for minor changes to metadata to support >>mixed stream and duplicated stream recording. >> >>Hi Partha, >> >>Ok so why in your example do the two streams contain different >>stream_id's if they both are referring to the same stream within the >CS? >> >>Regards >>Andy >> >> >> >>> -----Original Message----- >>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>> Sent: 30 May 2012 11:49 >>> To: Hutton, Andrew; john.2.stafford@bt.com >>> Cc: siprec@ietf.org >>> Subject: RE: [siprec] Proposal for minor changes to metadata to >>> support mixed stream and duplicated stream recording. >>> >>> Hi Andy, >>> >>> I think that we are in the same page. Duplication of single CS stream >>> into multiple RS stream is one of the usecase mentioned in the below >>> mail. Multiple label in "stream" element does not indicate the >>> duplication of the CS stream automatically. Apart from this, There is >>> a need of explicit grouping mechanism to say that two stream are >>> duplicate of each other. >>> >>> Thanks >>> Partha >>> >>> >-----Original Message----- >>> >From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] >>> >Sent: Tuesday, May 29, 2012 3:27 PM >>> >To: Ravindran, Parthasarathi; john.2.stafford@bt.com >>> >Cc: siprec@ietf.org >>> >Subject: RE: [siprec] Proposal for minor changes to metadata to >>> support >>> >mixed stream and duplicated stream recording. >>> > >>> >Hi Partha, >>> > >>> >Before looking at your reasons in more detail I want to check we are >>> on >>> >the same page. >>> > >>> >The case I think we are discussing is recoding the same CS stream >>> >(m- >>> >line) in multiple m line streams of one RS. (i.e. a single CS stream >>> is >>> >duplicated in to multiple RS streams). Is this also your >>> >understanding >>> ? >>> > >>> > >>> >Regards >>> >Andy >>> > >>> > >>> >> -----Original Message----- >>> >> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>> >> Sent: 28 May 2012 18:15 >>> >> To: Hutton, Andrew; john.2.stafford@bt.com >>> >> Cc: siprec@ietf.org >>> >> Subject: RE: [siprec] Proposal for minor changes to metadata to >>> >> support mixed stream and duplicated stream recording. >>> >> >>> >> Andy, >>> >> >>> >> Recording multiple m line in CS has to be represented as follows: >>> >> >>> >> >> >> session_id=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >>> >> >>> >> >>> >> >> >> session_id=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >>> >> >>> >> >>> >> >>> >> The reason for this approach in XML is due to the metadata model >>> >> constraints and the exact details are as follows: >>> >> >>> >> 1) Mapping of each individual label (SDP "m" line) to single >>> >> stream >>> by >>> >> which participantstream's attributes will explain about the stream >>> >> correctly. Say video label attribute is added in the stream >>> >> element during mid-dialog whereas the session is established with >>> >> audio >>> label >>> >> & stream, here video label association time is different from >>> >> audio label association time. >>> >> >>> >> 2) Partial update for each stream independently provide more >>> >> flexibility. (Add & Remove stream without impacting any other >>> stream). >>> >> >>> >> In case of multiple label exists within single stream as shown in >>> your >>> >> mail, >>> >> >>> >> 1) It is impossible to deduce the association and disassociation >>> time >>> >> of the individual label or SDP "m" line >>> >> 2) It is possible to have the wrong information like indicate one >>> >> of the stream in "recv" association whereas other stream is in >>"send" >>> >> association (Hypothetical scenario). >>> >> >>> >> So, stream XML element has to have single label attribute within >>> >> itself. >>> >> >>> >> Thanks >>> >> Partha >>> >> >>> >> >-----Original Message----- >>> >> >From: Hutton, Andrew >>> >> >[mailto:andrew.hutton@siemens-enterprise.com] >>> >> >Sent: Monday, May 28, 2012 7:46 PM >>> >> >To: Ravindran, Parthasarathi; john.2.stafford@bt.com >>> >> >Cc: siprec@ietf.org >>> >> >Subject: RE: [siprec] Proposal for minor changes to metadata to >>> >> support >>> >> >mixed stream and duplicated stream recording. >>> >> > >>> >> >Hi All, >>> >> > >>> >> >I just want to make sure I understand the results of this >>> discussion >>> >> and >>> >> >whether we have consensus. >>> >> > >>> >> >I am assuming we have consensus to move to using "stream_id" >>> >> >rather >>> >> than >>> >> >"id" as this is what the XML experts are telling us is correct. >>> >> > >>> >> >Mixed Stream Recording >>> >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >>> >> > >>> >> >For the mixed stream scenario in which streams from two CS's are >>> >> >mixed in to a single RS stream then the following seems to be >>> >> >what >>> we >>> >> >have settled on. >>> >> > >>> >> > >> >> > session_id=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >>> >> > >>> >> > >>> >> > >> >> > session_id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >>> >> > >>> >> > >>> >> > >>> >> > >>> >> >Recoding same CS stream in multiple m line streams of 1 RS >>> >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >> > >>> >> >I am not sure I have it right for this case but I think assuming >>> the >>> >> >change to use "stream_id" and "session_id" would result in the >>> >> >following: >>> >> > >>> >> > >> >> > session_id=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >>> >> > >>> >> > >>> >> > >>> >> > >>> >> >Do we have any issues with this? >>> >> > >>> >> >Regards >>> >> >Andy (SIPREC Co-Chair). >>> >> > >>> >> > >>> >> > >>> >> > >>> >> >> -----Original Message----- >>> >> >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] >>> >> >> On Behalf Of Ravindran, Parthasarathi >>> >> >> Sent: 16 May 2012 08:30 >>> >> >> To: Ravindran, Parthasarathi; john.2.stafford@bt.com >>> >> >> Cc: siprec@ietf.org >>> >> >> Subject: Re: [siprec] Proposal for minor changes to metadata to >>> >> >> support mixed stream and duplicated stream recording. >>> >> >> >>> >> >> Hi all, >>> >> >> >>> >> >> In case there is no objection to the below proposal with >>> >> >> explicit id instead of "id" usage till 23rd May (Next >>> >> >> Wednesday), I think that >>> >> it >>> >> >> is better to incorporate in (-07) metadata draft as these >>> >> >> changes helps for the progresses of the metadata draft. Please >>> >> >> let me >>> know >>> >> >> your opinion on the same. >>> >> >> >>> >> >> Thanks >>> >> >> Partha >>> >> >> >>> >> >> >-----Original Message----- >>> >> >> >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] >>> On >>> >> >> Behalf >>> >> >> >Of Ravindran, Parthasarathi >>> >> >> >Sent: Monday, May 14, 2012 5:40 PM >>> >> >> >To: john.2.stafford@bt.com >>> >> >> >Cc: siprec@ietf.org >>> >> >> >Subject: Re: [siprec] Proposal for minor changes to metadata >>> >> >> >to >>> >> >> support >>> >> >> >mixed stream and duplicated stream recording. >>> >> >> > >>> >> >> >John, >>> >> >> > >>> >> >> >My example is to show how to represent single stream in two CS >>> and >>> >> it >>> >> >> is >>> >> >> >as follows: >>> >> >> > >>> >> >> > >> >> >> > session_id=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D= =3D"> >>> >> >> > >>> >> >> > >>> >> >> > >> >> >> > session_id=3D" zSfPoSvdSDCmU3A3TRDxAw=3D=3D"= > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> >In the above example, Axzg12XHdhjelfjhdldjf;34jn78=3D=3D is the >>> single >>> >> >> >stream id which is Used by two CS namely >>> >> zzlafnvvjlCHllaHF6mn8kkSS=3D=3D >>> >> >> >& zSfPoSvdSDCmU3A3TRDxAw=3D=3D. >>> >> >> > >>> >> >> >The trouble with multiple label in single stream is that the >>> >> handling >>> >> >> of >>> >> >> >participantstream association for each of the label >>> >> >> >individually >>> >> >> within >>> >> >> >the single stream element. >>> >> >> > >>> >> >> >Duplicate stream recording has to have separate streams to >>> >> >> >distinguish the actual & duplicate stream. >>> >> >> > >>> >> >> > >>> >> >> >Thanks >>> >> >> >Partha >>> >> >> > >>> >> >> >>-----Original Message----- >>> >> >> >>From: john.2.stafford@bt.com [mailto:john.2.stafford@bt.com] >>> >> >> >>Sent: Monday, May 14, 2012 5:22 PM >>> >> >> >>To: Ravindran, Parthasarathi >>> >> >> >>Cc: siprec@ietf.org >>> >> >> >>Subject: RE: [siprec] Proposal for minor changes to metadata >>> >> >> >>to >>> >> >> support >>> >> >> >>mixed stream and duplicated stream recording. >>> >> >> >> >>> >> >> >>Partha, >>> >> >> >> >>> >> >> >>You are suggesting >>> >> >> >>>>>> >> >> >> >>>>>> session_id=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >>>>>> >> >> >> >>>>>> session_id=3D" zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >>> >> >> >>>>>> >>> >> >> > >>> >> >> >>>>>> >> >> >> >>>>>> session_id=3D" zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >>>>>> >> >> >> >>>>>> session_id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >>I am confused, what is the example you show supposed to >>> >> >> >>respresent >>> >> ? >>> >> >> >> >>> >> >> >> >>> >> >> >>To hark back to my original request, what is your objection >>> >> >> >>to the following, as it seems simpler to me than what you are >>> >suggesting: >>> >> >> >> >>> >> >> >>>>>> 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. >>> >> >> >> >>> >> >> >>>>>> Mixed Stream Recording: >>> >> >> >>>>>> >>> >> >> >>>>>> 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: >>> >> >> >>>>>> >>> >> >> >>>>>> >> >> >> >>>>>> session=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >>>>>> >> >> >> >>>>>> session=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >> >>> >> >> >>>>>> >>> >> >> >>>>>> Duplicate Stream Recording 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=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >>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: 10 May 2012 21:02 >>> >> >> >>To: Joe Hildebrand >>> >> >> >>Cc: siprec@ietf.org >>> >> >> >>Subject: Re: [siprec] Proposal for minor changes to metadata >>> >> >> >>to >>> >> >> support >>> >> >> >>mixed stream and duplicated stream recording. >>> >> >> >> >>> >> >> >>On 5/10/12 11:20 AM, Joe Hildebrand wrote: >>> >> >> >>> id is supposed to be unique across the entire document. In >>> >> >> >>> some processing software (such as CSS), id has special >>> >> >> >>> syntax that takes advantage of that assumption. >>> >> >> >> >>> >> >> >>OK, I'll take your word for it, since it sounds like >>> >> >> >>otherwise >>> it >>> >> >> would >>> >> >> >>take me down a rat hole that I would rather avoid. >>> >> >> >> >>> >> >> >> Thanks, >>> >> >> >> Paul >>> >> >> >> >>> >> >> >>> On 5/10/12 7:13 AM, "Ravindran, >>> >> >> >>> Parthasarathi" >>> >> >> >>> wrote: >>> >> >> >>> >>> >> >> >>>> Paul, >>> >> >> >>>> >>> >> >> >>>> XML:id attribute is mentioned in http://www.w3.org/TR/xml- >>> id/ >>> >> and >>> >> >> >>>> each element in XML document has at most one single unique >>> >> >> >identifier >>> >> >> >>"id". >>> >> >> >>>> >>> >> >> >>>> Including Joe in this mail thread. >>> >> >> >>>> >>> >> >> >>>> Thanks >>> >> >> >>>> Partha >>> >> >> >>>> >>> >> >> >>>>> -----Original Message----- >>> >> >> >>>>> From: siprec-bounces@ietf.org >>> >> >> >>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul >>> >> >> >>>>> Kyzivat >>> >> >> >>>>> Sent: Wednesday, May 09, 2012 7:45 PM >>> >> >> >>>>> To: siprec@ietf.org >>> >> >> >>>>> Subject: Re: [siprec] Proposal for minor changes to >>> metadata >>> >> to >>> >> >> >>>>> support mixed stream and duplicated stream recording. >>> >> >> >>>>> >>> >> >> >>>>> The new form reads nicely, but it is a bit verbose. >>> >> >> >>>>> I'd be interested to hear more about why "id" is >>> >> >> >>>>> *special* >>> in >>> >> >> XML. >>> >> >> >>>>> >>> >> >> >>>>> Thanks, >>> >> >> >>>>> Paul >>> >> >> >>>>> >>> >> >> >>>>> On 5/9/12 9:44 AM, Ravindran, Parthasarathi wrote: >>> >> >> >>>>>> Hi John, >>> >> >> >>>>>> >>> >> >> >>>>>> Sorry for the delay reply. In the object model, there is >>> >> >> >>>>>> unique- >>> >> >> id >>> >> >> >>>>>> and association related to the object. In case of XML >>> >> >> >>>>>> representation, unique-id of the object is represented >>> >> >> >>>>>> as XML attribute "id" and the association of the object >>> >> >> >>>>>> is >>> >> represented >>> >> >> by >>> >> >> >>second attribute . >>> >> >> >>>>>> >>> >> >> >>>>>> While I discussing with XML experts, I understand that >>> "id" >>> >> has >>> >> >> >>>>>> special meaning in XML and it should not be repeated. >>> >> >> >>>>>> So, I'm proposing to have object name with id for both >>> >> >> >>>>>> attributes and >>> >> >> XML >>> >> >> >>>>> looks as follows: >>> >> >> >>>>>> >>> >> >> >>>>>> >> >> >> >>>>>> session_id=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >>>>>> >> >> >> >>>>>> session_id=3D" zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >>> >> >> >>>>>> >stream_id=3D"EiXGlc+4TruqqoDaNE76ag=3D=3D" >>> >> >> >>>>>> session_id=3D" zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >>> >> >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >>>>>> >> >> >> >>>>>> session_id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >>>>>> Please let me know your opinion on the same. >>> >> >> >>>>>> >>> >> >> >>>>>> Thanks >>> >> >> >>>>>> >>> >> >> >>>>>> Partha >>> >> >> >>>>>> >>> >> >> >>>>>> *From:*john.2.stafford@bt.com >>> >> >> >>>>>> [mailto:john.2.stafford@bt.com] >>> >> >> >>>>>> *Sent:* Thursday, March 29, 2012 2:35 PM >>> >> >> >>>>>> *To:* Ravindran, Parthasarathi; siprec@ietf.org >>> >> >> >>>>>> *Subject:* RE: [siprec] Proposal for minor changes to >>> >> metadata >>> >> >> to >>> >> >> >>>>>> support mixed stream and duplicated stream recording. >>> >> >> >>>>>> >>> >> >> >>>>>> Partha, >>> >> >> >>>>>> >>> >> >> >>>>>> so you are saying there is no need to allow 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 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 >>> >> >> >>>>>> | >>> >> >> >>>>>> _www.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 mixed stream and duplicated stream recording. >>> >> >> >>>>>> >>> >> >> >>>>>> 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 allowed in a stream element, the meaning would be >>> >> >> >>>>>> that the stream is recorded in all of the referenced >>> >> >> >>>>>> recording m-line >>> >> >> >>streams." >>> >> >> >>>>>> >>> >> >> >>>>>> Here, There are two CS's, 2 m'line and 1 RS. For >>> >> >> >>>>>> representing as per current XML schema is as follows, >>> >> >> >>>>>> >>> >> >> >>>>>> >> >> >> >>>>>> session=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >>>>>> >> >> >> >>>>>> session=3D" zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >> >> >> >>>>>> session=3D" zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >>> >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >>>>>> >> >> >> >>>>>> session=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >>>>>> Could you please explain the issue in the above >approach. >>> >> >> >>>>>> >>> >> >> >>>>>> Thanks >>> >> >> >>>>>> >>> >> >> >>>>>> Partha >>> >> >> >>>>>> >>> >> >> >>>>>> *From:*siprec-bounces@ietf.org>> >> 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 "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. >>> >> >> >>>>>> >>> >> >> >>>>>> 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. >>> >> >> >>>>>> >>> >> >> >>>>>> 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 >>> >> >> >>>>>> 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: >>> >> >> >>>>>> >>> >> >> >>>>>> >> >> >> >>>>>> session=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >>>>>> >> >> >> >>>>>> 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's 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"> >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >>>>>> Finally, we could have both the above scenarios >>> >> >> >>>>>> together, >>> >> where >>> >> >> >the >>> >> >> >>>>>> mixed two CS recording is duplicated: >>> >> >> >>>>>> >>> >> >> >>>>>> >> >> >> >>>>>> session=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >>>>>> >> >> >> >>>>>> 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. >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >>>>>> 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. >>> >> >> >>>>>> >>> >> >> >>>>>> 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 internet-drafts@ietf.org Mon Jul 2 23:03: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 61F6A21F853F; Mon, 2 Jul 2012 23:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 KlOBoyQX+Vlo; Mon, 2 Jul 2012 23:03:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFDA421F84FF; Mon, 2 Jul 2012 23:03:24 -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.21p1 Message-ID: <20120703060324.32593.96953.idtracker@ietfa.amsl.com> Date: Mon, 02 Jul 2012 23:03:24 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-07.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, 03 Jul 2012 06:03:25 -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 IETF. Title : Session Initiation Protocol (SIP) Recording Metadata Author(s) : Ram Mohan Ravindranath Parthasarathi Ravindran Paul Kyzivat Filename : draft-ietf-siprec-metadata-07.txt Pages : 48 Date : 2012-07-02 Abstract: Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes the metadata model as viewed by Session Recording Server(SRS) and the Recording metadata format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-siprec-metadata-07 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-metadata-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rmohanr@cisco.com Mon Jul 2 23:17: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 8182411E8134; Mon, 2 Jul 2012 23:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 iMxYxt+k80EO; Mon, 2 Jul 2012 23:17:03 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 586F611E813D; Mon, 2 Jul 2012 23:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=2322; q=dns/txt; s=iport; t=1341296230; x=1342505830; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=82MHX8+dERfG4VaGpERu3C7RC78LimO+dUbmL3AsmtY=; b=BZgYDh7hyeTUf/6QTxRJoREiuwkSlNpd4Mo302itI1YHcT3iWy0JCIv+ 37ADrSFQ1cMzd9Rw7EgTR0a5/p8s0hDeCmQmOiZR6+5d4rE/8oNrbVQut MJfu4uTXrCZjTTjQgshqw5+xTZTYWdWoGqiDzKiK7nGZwqpN160lGsh7L I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EALWN8k+tJXG//2dsb2JhbABFtmqBB4IaAQICAQEBDwEnNAsSAQg2NwslAgQBDQUJGYdpC5phoEaRUgOVNYESjQuBZoJf X-IronPort-AV: E=Sophos;i="4.77,514,1336348800"; d="scan'208";a="98212074" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 03 Jul 2012 06:17:10 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q636H67K021478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jul 2012 06:17:06 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.251]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0298.004; Tue, 3 Jul 2012 01:17:05 -0500 From: "Ram Mohan R (rmohanr)" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-metadata-07.txt Thread-Index: AQHNWON3OlmgoLp+ckaGnsJnnOC8Eg== Date: Tue, 3 Jul 2012 06:17:05 +0000 Message-ID: In-Reply-To: <20120703060324.32593.96953.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.65.79.193] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19014.003 x-tm-as-result: No--38.084300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <255BB9A0F29ED04D84D926D5518FB94A@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-07.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, 03 Jul 2012 06:17:04 -0000 Hi all, This version of the draft tries the incorporate the comments received in IETF 83 Refer to http://www.ietf.org/proceedings/83/minutes/minutes-83-siprec.pdf for the minutes. To summarize it has following changes: 1) Incorporated start/stop times for CS 2) Edits to CSRS association and ParticipantCSAssociation 3) Minor NITS received as comments in previous version 4) Modified the XML to have id as just id instead of group_id e.t.c and session instead of session_id. 5) Modified the examples to reflect the change in schema in [4] Please review the draft and provide your comments. Authors On 03/07/12 11:33 AM, "internet-drafts@ietf.org" wrote: > >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-07.txt > Pages : 48 > Date : 2012-07-02 > >Abstract: > Session recording is a critical requirement in many communications > environments such as call centers and financial trading. In some of > these environments, all calls must be recorded for regulatory, > compliance, and consumer protection reasons. Recording of a session > is typically performed by sending a copy of a media stream to a > recording device. This document describes the metadata model as > viewed by Session Recording Server(SRS) and the Recording metadata > format. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-siprec-metadata-07 > >A diff from previous version is available at: >http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-metadata-07 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec > From Leon.Portman@nice.com Mon Jul 2 23:28: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 4010621F84D1 for ; Mon, 2 Jul 2012 23:28:28 -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 3Dkjo4W2wrbG for ; Mon, 2 Jul 2012 23:28:27 -0700 (PDT) Received: from mailil.nice.com (mailil.nice.com [192.114.148.4]) by ietfa.amsl.com (Postfix) with ESMTP id EE75111E8134 for ; Mon, 2 Jul 2012 23:28:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,515,1336338000"; d="scan'208";a="3320688" Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Tue, 3 Jul 2012 09:28:32 +0300 From: Leon Portman To: "Richard L. Barnes" , "siprec@ietf.org" Date: Tue, 3 Jul 2012 09:28:31 +0300 Thread-Topic: [siprec] Security review of draft-ietf-siprec-protocol-05 Thread-Index: Ac1VSk411AjtFtIySkmPdaXHLTD4SQDmUHwg Message-ID: <07465C1D981ABC41A344374066AE1A2C3A9036B0EA@TLVMBX01.nice.com> References: <657A3659-61DB-433A-97F4-593ECD31DB1B@bbn.com> In-Reply-To: <657A3659-61DB-433A-97F4-593ECD31DB1B@bbn.com> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Security review of draft-ietf-siprec-protocol-05 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, 03 Jul 2012 06:28:28 -0000 Richard Hi Thank you very much for the review. It is very helpful. Please see below my= answers. Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Richard L. Barnes Sent: Thursday, June 28, 2012 6:58 PM To: siprec@ietf.org Subject: [siprec] Security review of draft-ietf-siprec-protocol-05 Dear SIPREC, At the SIPREC meeting at the last IETF, I volunteered to do a security revi= ew of the SIPREC protocol document. Thanks to the chairs increasingly pers= istent reminders, I've finally gotten around to doing it :) At one level, my basic question is: How is this better than just doing a PC= AP? I can see the efficiency gains in terms of RTP handling, but I'm conce= rned that (1) the security requirements need to be more tightly specified, = and (2) there seems to be quite a bit of information loss. [LeonP] PCAP method (passive sniffing) requires usage of SPAN ports in orde= r to forward RTP traffic towards recording system. It used to be popular me= thod of recording but now Enterprises prefer active methods for following r= easons: less configuration overhead, support for remote recording systems, = better security, support for selective recording etc. I agree on some level= of information loss but we do plan to support different extension of metad= ata so all additional information still can be captured. Starting with the most obvious part: The Security Considerations needs to b= e tightened up. This document benefits from the fact that the SRC and the = SRS are logically within the same administrative domain, so it should be fe= asible to establish credentials that they use to authenticate one another. = So the document should REQUIRE that the SRC and the SRS mutually authentic= ate to one another, either using SIP authentication or using TLS authentica= tion beneath SIPS. [LeonP] Agree At the media level, is there a reason that you don't specify a keying mecha= nism? Why would you not just specify DTLS-SRTP? It may also be worth noti= ng that because this protocol will tend to be used within an administrative= domain, the need for confidentiality is lower than in the general Internet= ; however, there is still a strong need for authentication. So this docume= nt should REQUIRE that implementations support the SRTP_NULL_HMAC_SHA1_* pr= otection profiles and RECOMMEND support for others. [LeonP] Actually we wanted to support all standard keying mechanisms. Howev= er because SIPREC media session is established in parallel to the actual co= mmunication session, we want to prefer to use keying mechanism with fastest= session negotiation time in order to minimize lost of recoding (media clip= ping). DTLS-SRTP is problematic from this point of view. Speaking of SRTP, it's not clear whether there's a requirement for the SRC/= SRS to have access to the keys used to protect secure media, in the case wh= ere the SRC is a middlebox, not terminating media. To support this case, y= ou would need (1) a way to get the key from the endpoint to the SRC, and (2= ) a way to get the key from the SRC ot the SRS. I would suggest looking at= EKT / KTR for both of these [http://tools.ietf.org/html/draft-mcgrew-srtp-= ekt-06#section-4][http://tools.ietf.org/html/draft-wing-avt-dtls-srtp-key-t= ransport-03]. [LeonP] Our assumption was that it is out of scope of this work how SRC wi= ll get keys. We used to have text about it and it was removed. We should di= scuss it little more. Finally, it seems like a gap that the SIP signaling information for the rec= orded session doesn't get passed off to the SRC. Section 8 of the current = document describes how to pass "metadata", but doesn't really define what t= he metadata is.=20 [LeonP] We have separate draft for the description of the metadata Hope this helps, --Richard _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Mon Jul 9 06:45: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 9B4C311E8079 for ; Mon, 9 Jul 2012 06:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 lL99zoWc7eua for ; Mon, 9 Jul 2012 06:45:08 -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 C08D411E8083 for ; Mon, 9 Jul 2012 06:45:07 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 8D7B723F048C for ; Mon, 9 Jul 2012 15:45:31 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.99]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0309.002; Mon, 9 Jul 2012 15:45:31 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-metadata-07.txt Thread-Index: AQHNWOGW2wZyYKdvMkemVVUMYzwTFZcW86SAgAoMM+A= Date: Mon, 9 Jul 2012 13:45:30 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF043651@MCHP04MSX.global-ad.net> References: <20120703060324.32593.96953.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-07.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, 09 Jul 2012 13:45:08 -0000 Hi All, We need a few volunteers to do a full review of the SIPREC metadata draft. If you are able to volunteer for this please let me know. If we could have some people review the draft before IETF84 then that would= be perfect. Regards Andy (SIPREC Co-Chair). > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ram Mohan R (rmohanr) > Sent: 03 July 2012 07:17 > To: internet-drafts@ietf.org; i-d-announce@ietf.org > Cc: siprec@ietf.org > Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-07.txt >=20 > Hi all, >=20 > This version of the draft tries the incorporate the comments received > in > IETF 83 > Refer to http://www.ietf.org/proceedings/83/minutes/minutes-83- > siprec.pdf > for the minutes. >=20 > To summarize it has following changes: > 1) Incorporated start/stop times for CS > 2) Edits to CSRS association and ParticipantCSAssociation > 3) Minor NITS received as comments in previous version > 4) Modified the XML to have id as just id instead of group_id e.t.c and > session instead of session_id. > 5) Modified the examples to reflect the change in schema in [4] >=20 > Please review the draft and provide your comments. >=20 > Authors >=20 > On 03/07/12 11:33 AM, "internet-drafts@ietf.org" > wrote: >=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. > > > > Title : Session Initiation Protocol (SIP) Recording > Metadata > > Author(s) : Ram Mohan Ravindranath > > Parthasarathi Ravindran > > Paul Kyzivat > > Filename : draft-ietf-siprec-metadata-07.txt > > Pages : 48 > > Date : 2012-07-02 > > > >Abstract: > > Session recording is a critical requirement in many communications > > environments such as call centers and financial trading. In some > of > > these environments, all calls must be recorded for regulatory, > > compliance, and consumer protection reasons. Recording of a > session > > is typically performed by sending a copy of a media stream to a > > recording device. This document describes the metadata model as > > viewed by Session Recording Server(SRS) and the Recording metadata > > format. > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-ietf-siprec-metadata-07 > > > >A diff from previous version is available at: > >http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-metadata-07 > > > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >siprec mailing list > >siprec@ietf.org > >https://www.ietf.org/mailman/listinfo/siprec > > >=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From prvs=1537f3259c=MSmith@dss-corp.com Mon Jul 9 07:14: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 9966A21F869F for ; Mon, 9 Jul 2012 07:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 M+6e+n0ar4Vp for ; Mon, 9 Jul 2012 07:14:31 -0700 (PDT) Received: from spam.dss-corp.com (spam.dss-corp.com [67.214.118.46]) by ietfa.amsl.com (Postfix) with ESMTP id C3DE321F8692 for ; Mon, 9 Jul 2012 07:14:30 -0700 (PDT) Received: from spam.dss-corp.com (127.0.0.1) by spam.dss-corp.com (MlfMTA v3.2r9) id hvbke60171s2 for ; Mon, 9 Jul 2012 10:21:19 -0400 (envelope-from ) Received: from exc.dss-corp.com ([192.168.1.5]) by spam.dss-corp.com (SonicWALL 7.2.4.3929) with ESMTP; Mon, 09 Jul 2012 10:21:18 -0400 Received: from EXC01.dss.lan ([fe80::109b:ad4:1a47:2813]) by exc01.dss.lan ([fe80::109b:ad4:1a47:2813%13]) with mapi; Mon, 9 Jul 2012 10:14:34 -0400 From: Michael Smith To: "siprec@ietf.org" Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-metadata-07.txt Thread-Index: AQHNWOGZ1iutGtCPoUO5Vodq+FzB9JcXWDqAgAnrRgD//8LLgA== Date: Mon, 9 Jul 2012 14:14:43 +0000 Message-ID: <05D56509F27CCE4DAF8136C02386880D68647287@exc01.dss.lan> References: <20120703060324.32593.96953.idtracker@ietfa.amsl.com> <9F33F40F6F2CD847824537F3C4E37DDF043651@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF043651@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mlf-Version: 7.2.4.3929 X-Mlf-UniqueId: o201207091421180019119 Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-07.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, 09 Jul 2012 14:14:32 -0000 Andy, I volunteer to do a review; is this the correct version: https://datatracke= r.ietf.org/doc/draft-ietf-siprec-metadata/ ? Note: I'll limit my comments to basic editorial stuff, and things I'm prett= y sure are real issues, since I've only recently become familiar with SIPRE= C and don't want to waste your time on things I simply don't understand. BT= W, Brian Rosen knows me from NENA work. I'm on his LTD working group, and l= ead the NG9-1-1 PSAP working group, and the recording test committee. We've= proposed using SIPREC as the media recording protocol in NG9-1-1. Reviewing this draft will help me understand better, and hopefully provide = some usable feedback to you. Regards, Michael Smith Chief Technologist Ph: 606.877.2788 | Mobile: 606.231.0243=20 DSS Corporation / Equature 18311=A0=A0 W. Ten Mile Road, Suite 200 Southfield, MI - 48075 Tel: 1-888.305.3428 Fax: 1-248.569.6567 www.dss-corp.com www.dispatchimprovement.com -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Hutton, Andrew Sent: Monday, July 09, 2012 9:46 AM To: siprec@ietf.org Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-07.txt Hi All, We need a few volunteers to do a full review of the SIPREC metadata draft. If you are able to volunteer for this please let me know. If we could have some people review the draft before IETF84 then that would= be perfect. Regards Andy (SIPREC Co-Chair). > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Ram Mohan R (rmohanr) > Sent: 03 July 2012 07:17 > To: internet-drafts@ietf.org; i-d-announce@ietf.org > Cc: siprec@ietf.org > Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-07.txt >=20 > Hi all, >=20 > This version of the draft tries the incorporate the comments received=20 > in IETF 83 Refer to=20 > http://www.ietf.org/proceedings/83/minutes/minutes-83- > siprec.pdf > for the minutes. >=20 > To summarize it has following changes: > 1) Incorporated start/stop times for CS > 2) Edits to CSRS association and ParticipantCSAssociation > 3) Minor NITS received as comments in previous version > 4) Modified the XML to have id as just id instead of group_id e.t.c=20 > and session instead of session_id. > 5) Modified the examples to reflect the change in schema in [4] >=20 > Please review the draft and provide your comments. >=20 > Authors >=20 > On 03/07/12 11:33 AM, "internet-drafts@ietf.org" > wrote: >=20 > > > >A New Internet-Draft is available from the on-line Internet-Drafts=20 > >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-07.txt > > Pages : 48 > > Date : 2012-07-02 > > > >Abstract: > > Session recording is a critical requirement in many communications > > environments such as call centers and financial trading. In some > of > > these environments, all calls must be recorded for regulatory, > > compliance, and consumer protection reasons. Recording of a > session > > is typically performed by sending a copy of a media stream to a > > recording device. This document describes the metadata model as > > viewed by Session Recording Server(SRS) and the Recording metadata > > format. > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-ietf-siprec-metadata-07 > > > >A diff from previous version is available at: > >http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-metadata-07 > > > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >siprec mailing list > >siprec@ietf.org > >https://www.ietf.org/mailman/listinfo/siprec > > >=20 >=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 Mon Jul 9 10:34: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 CA7F321F87A4 for ; Mon, 9 Jul 2012 10:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 Or2Y-Ku1cGX8 for ; Mon, 9 Jul 2012 10:34:40 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3970621F877D for ; Mon, 9 Jul 2012 10:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=1900; q=dns/txt; s=iport; t=1341855303; x=1343064903; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Y+8vomLS4LHrAsaht/CIyRE+QA1C/vFM5DJVZKP87b8=; b=RDKEjGtciqJw1AL98KxqiriwVb/VS+fD34SvW50zqHYXnoebDbIWcxT6 PbhQY2OOi6fM6ohM6Sdie966WuN4kbPuvTupTQb+NGEkHLGsaiIuRWq7H KDxSowYQtlZzlWgcV+h2N7+j3uiFw3kPbx2UdJSE8shgfRtSLYU5T3ZmC o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAOsV+0+tJV2d/2dsb2JhbABFt3aBB4IgAQIEEgEnPQISAQg2QhsBBgMCBA4FCRmHawubZKAPkUwDlTaBEo0NgWaCXw X-IronPort-AV: E=Sophos;i="4.77,553,1336348800"; d="scan'208";a="100090090" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 09 Jul 2012 17:35:02 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q69HZ2Et012618 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Jul 2012 17:35:02 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.114]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Mon, 9 Jul 2012 12:35:02 -0500 From: "Ram Mohan R (rmohanr)" To: "siprec@ietf.org" Thread-Topic: New Version Notification for draft-ram-siprec-callflows-00.txt Thread-Index: AQHNXfXNv7RiTaVngE24CJ76DOYduZch5myA Date: Mon, 9 Jul 2012 17:35:01 +0000 Message-ID: In-Reply-To: <20120709171023.18128.40878.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.65.71.147] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19028.005 x-tm-as-result: No--37.456600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] FW: New Version Notification for draft-ram-siprec-callflows-00.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, 09 Jul 2012 17:34:44 -0000 Hi all, As per the discussions in the last IETF [ see in the minuteshttp://tools.ietf.org/wg/siprec/minutes?item=3Dminutes-83-siprec.htm= l] we have come up with a call flow document that has some basic flows showing the snippet of metadata sent from SRC to SRS. This document is written only as a supporting material to the SIPREC metadata draft [ draft-ietf-siprec-metadata]. Comments welcome Regards Authors. > >On 09/07/12 10:40 PM, "internet-drafts@ietf.org" > wrote: > >A new version of I-D, draft-ram-siprec-callflows-00.txt >has been successfully submitted by Ram Mohan Ravindranath and posted to >the >IETF repository. > >Filename: draft-ram-siprec-callflows >Revision: 00 >Title: Session Initiation Protocol (SIP) Recording Call Flows >Creation date: 2012-07-09 >WG ID: Individual Submission >Number of pages: 22 >URL: =20 >http://www.ietf.org/internet-drafts/draft-ram-siprec-callflows-00.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-ram-siprec-callflows >Htmlized: http://tools.ietf.org/html/draft-ram-siprec-callflows-00 > > >Abstract: > Session recording is a critical requirement in many communications > environments such as call centers and financial trading. In some of > these environments, all calls must be recorded for regulatory, > compliance, and consumer protection reasons. Recording of a session > is typically performed by sending a copy of a media stream to a > recording device. This document lists call flows that has snapshot > of metadata sent from SRC to SRS, the metadata format for which is > described in [I-D.ietf-siprec-metadata] . This is purely an > informational document that is written to support the model defined > the metadata draft. > > =20 > =20 > > >The IETF Secretariat > From eckelcu@cisco.com Wed Jul 11 10:12: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 4C84411E8113 for ; Wed, 11 Jul 2012 10:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.471 X-Spam-Level: X-Spam-Status: No, score=-10.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 tCJtqBpZCZc9 for ; Wed, 11 Jul 2012 10:12:47 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9A87711E811B for ; Wed, 11 Jul 2012 10:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=828; q=dns/txt; s=iport; t=1342026797; x=1343236397; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=J/BGv8Q3AoWHcRE43CegMcY8kaADb0sdCl6xnZZOEtI=; b=CqAF+q1eoCxa3n3zH4kM2uisOeQybbboTqVLh6DdRdA0+TkwXigk6tqa H8GD1GgMpnWsWEZzYMGnMILDnvvB1PzyiyqJ8UDJmMHAFe8ysh/fW9HSH Uuv52yZHnYghbyB8D4jln59EONCzRWaELFazY4leVUfSVKg+rqlDE/Wvc U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAICz/U+tJXG+/2dsb2JhbABFt2yBB4IiAQQSASdRASoUQiYBBBsah2oBnBuBKKAdkE5gA6NagWaCXw X-IronPort-AV: E=Sophos;i="4.77,569,1336348800"; d="scan'208";a="100920938" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 11 Jul 2012 17:13:15 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6BHDEUH008095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 11 Jul 2012 17:13:14 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.205]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0298.004; Wed, 11 Jul 2012 12:13:14 -0500 From: "Charles Eckel (eckelcu)" To: "siprec@ietf.org" Thread-Topic: proposed update to RTP handling section of protocol draft Thread-Index: Ac1fiHQe8s1eJCUpQ9GCasGJMmIjjQ== Date: Wed, 11 Jul 2012 17:13:13 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882803A403@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.122.35] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19032.005 x-tm-as-result: No--37.894300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] proposed update to RTP handling section of protocol draft 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, 11 Jul 2012 17:12:48 -0000 I am in the process of updating the RTP handling section (section 7) of the= protocol draft. Per the consensus at IETF 83, the changes include expandin= g the recommendations to cover SIPREC aware UAs and adding a section on RTP= session usage by the SRC to deliver media streams to the SRS (e.g. using m= ultiple m-lines, SSRC multiplexing, mixing). In doing so, it seems best to me to rearrange the sections as follows: 7. RTP Handling 7.1 RTP Mechanisms 7.1.1 - 7.1.9 (previously sections 7.2 - 7.9 in version 05 of draft) 7.2 Roles (previously section 7.1 in version 05 of draft) 7.3 Examples of RTP Usage by SRC (new, based on IETF 83 presentation) 7.3.1 Multiple m-lines 7.3.2 SSRC Multiplexing 7.3.3 Mixing Please let me know if you have any concerns or alternate suggestions. Cheers, Charles=20 From pkyzivat@alum.mit.edu Wed Jul 11 10:24: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 1C28F11E8101 for ; Wed, 11 Jul 2012 10:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.270, 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 16bdYuxiH340 for ; Wed, 11 Jul 2012 10:24:07 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC8111E80E8 for ; Wed, 11 Jul 2012 10:24:07 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta15.westchester.pa.mail.comcast.net with comcast id Z3fD1j0021HzFnQ5F5QlGJ; Wed, 11 Jul 2012 17:24:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id Z5Qf1j00u3ZTu2S3a5Qf5x; Wed, 11 Jul 2012 17:24:40 +0000 Message-ID: <4FFDB6D4.7010609@alum.mit.edu> Date: Wed, 11 Jul 2012 13:24:36 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <92B7E61ADAC1BB4F941F943788C0882803A403@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C0882803A403@xmb-aln-x08.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] proposed update to RTP handling section of protocol draft 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, 11 Jul 2012 17:24:08 -0000 Charles, Ram and Partha and I were just discussing the BT "turret" use case. In this case they want to record a "mix" of media from multiple independent CS media streams onto a single RS m-line. (I guess this is an optimization.) When doing this, there is a choice of how to do the "mix". It could be just running multiple independent RTP streams over the single RTP session. Or it could be a real mix, with a single SSRC and one or several CSRCs. I don't know what we want to say about this, or where it ought to go. But if we don't say something, somewhere, I doubt that there would be much chance of interoperability. Thanks, Paul On 7/11/12 1:13 PM, Charles Eckel (eckelcu) wrote: > I am in the process of updating the RTP handling section (section 7) of the protocol draft. Per the consensus at IETF 83, the changes include expanding the recommendations to cover SIPREC aware UAs and adding a section on RTP session usage by the SRC to deliver media streams to the SRS (e.g. using multiple m-lines, SSRC multiplexing, mixing). > In doing so, it seems best to me to rearrange the sections as follows: > > 7. RTP Handling > 7.1 RTP Mechanisms > 7.1.1 - 7.1.9 (previously sections 7.2 - 7.9 in version 05 of draft) > 7.2 Roles (previously section 7.1 in version 05 of draft) > 7.3 Examples of RTP Usage by SRC (new, based on IETF 83 presentation) > 7.3.1 Multiple m-lines > 7.3.2 SSRC Multiplexing > 7.3.3 Mixing > > Please let me know if you have any concerns or alternate suggestions. > > Cheers, > Charles > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From eckelcu@cisco.com Wed Jul 11 15:47: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 751B311E815F for ; Wed, 11 Jul 2012 15:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.484 X-Spam-Level: X-Spam-Status: No, score=-10.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 UnuwblBN3YnM for ; Wed, 11 Jul 2012 15:47:32 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF0211E812C for ; Wed, 11 Jul 2012 15:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3059; q=dns/txt; s=iport; t=1342046884; x=1343256484; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=IpkfkhlD4b2uNKXT1i5sjvLLRVdph2XK8tIFUmopeO0=; b=JUrUc9fKJzuq1QpLPPqztTQkvpaTw7nOoDBoy8AykkyjystSpvYzWjHS Ofb09lUGA+ZC9x3ZPg6X7T4bGSHiYnKhaf11tYCgVmXVmfIMRVXSuIjMr UR5uwmgvl1Yr276zCfjaCdBui1z3wWQsQMzeF6IMtI36q9NveDxDpXM5K M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKAB/k+tJXG9/2dsb2JhbABFDrdlgQeCIAEBAQQBAQEPASc0FwQCAQgOAwQBAQEKFAkHJwsUCQgBAQQBEggah2oBC51UoCkEi0CFDmADo1qBZoImOQ X-IronPort-AV: E=Sophos;i="4.77,569,1336348800"; d="scan'208";a="98003913" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 11 Jul 2012 22:48:04 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6BMm3Zj020480 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jul 2012 22:48:03 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.205]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0298.004; Wed, 11 Jul 2012 17:48:03 -0500 From: "Charles Eckel (eckelcu)" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] proposed update to RTP handling section of protocol draft Thread-Index: Ac1fiHQe8s1eJCUpQ9GCasGJMmIjjQAK3/QAAACXQSA= Date: Wed, 11 Jul 2012 22:48:03 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882803AEED@xmb-aln-x08.cisco.com> References: <92B7E61ADAC1BB4F941F943788C0882803A403@xmb-aln-x08.cisco.com> <4FFDB6D4.7010609@alum.mit.edu> In-Reply-To: <4FFDB6D4.7010609@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.122.35] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19034.001 x-tm-as-result: No--60.546000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] proposed update to RTP handling section of protocol draft 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, 11 Jul 2012 22:47:33 -0000 Hi Paul, My current plan is to provide examples in which an SRC uses multiple m-line= s, SSRC multiplexing, or mixing, without making an explicitly recommendatio= ns as to when one method is more appropriate than another. I will include a= discussion of what happens when the SRS does not support or understand the= RTP session usage chosen by the SRC. In this light, the turret use case co= uld work in either manner you described; however, multiplexing multiple RTP= session with a single m-line would require the definition and negotiation = a new multiplexing mechanism, such as BUNDLE or SHIM. I am not planning to = provide any details regarding those at this time. We can of course add them= if we determine one or the other or both required or recommended for SIPRE= C. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Wednesday, July 11, 2012 10:25 AM > To: siprec@ietf.org > Subject: Re: [siprec] proposed update to RTP handling section of protocol > draft >=20 > Charles, >=20 > Ram and Partha and I were just discussing the BT "turret" use case. In > this case they want to record a "mix" of media from multiple independent > CS media streams onto a single RS m-line. (I guess this is an optimizatio= n.) >=20 > When doing this, there is a choice of how to do the "mix". It could be > just running multiple independent RTP streams over the single RTP > session. Or it could be a real mix, with a single SSRC and one or > several CSRCs. >=20 > I don't know what we want to say about this, or where it ought to go. > But if we don't say something, somewhere, I doubt that there would be > much chance of interoperability. >=20 > Thanks, > Paul >=20 > On 7/11/12 1:13 PM, Charles Eckel (eckelcu) wrote: > > I am in the process of updating the RTP handling section (section 7) of= the > protocol draft. Per the consensus at IETF 83, the changes include expandi= ng > the recommendations to cover SIPREC aware UAs and adding a section on > RTP session usage by the SRC to deliver media streams to the SRS (e.g. us= ing > multiple m-lines, SSRC multiplexing, mixing). > > In doing so, it seems best to me to rearrange the sections as follows: > > > > 7. RTP Handling > > 7.1 RTP Mechanisms > > 7.1.1 - 7.1.9 (previously sections 7.2 - 7.9 in version 05 of draft) > > 7.2 Roles (previously section 7.1 in version 05 of draft) > > 7.3 Examples of RTP Usage by SRC (new, based on IETF 83 presentation) > > 7.3.1 Multiple m-lines > > 7.3.2 SSRC Multiplexing > > 7.3.3 Mixing > > > > Please let me know if you have any concerns or alternate suggestions. > > > > Cheers, > > Charles > > _______________________________________________ > > 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 pkyzivat@alum.mit.edu Wed Jul 11 16:16: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 BAAE611E80F8 for ; Wed, 11 Jul 2012 16:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267, 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 NGTmyyfTd6qG for ; Wed, 11 Jul 2012 16:16:07 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id C4BB111E80BE for ; Wed, 11 Jul 2012 16:16:06 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta06.westchester.pa.mail.comcast.net with comcast id ZBEH1j0040Fqzac56BGg3F; Wed, 11 Jul 2012 23:16:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id ZBGd1j01F3ZTu2S3UBGd2G; Wed, 11 Jul 2012 23:16:38 +0000 Message-ID: <4FFE0955.6060609@alum.mit.edu> Date: Wed, 11 Jul 2012 19:16:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <92B7E61ADAC1BB4F941F943788C0882803A403@xmb-aln-x08.cisco.com> <4FFDB6D4.7010609@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C0882803AEED@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C0882803AEED@xmb-aln-x08.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] proposed update to RTP handling section of protocol draft 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, 11 Jul 2012 23:16:07 -0000 On 7/11/12 6:48 PM, Charles Eckel (eckelcu) wrote: > Hi Paul, > > My current plan is to provide examples in which an SRC uses multiple m-lines, SSRC multiplexing, or mixing, without making an explicitly recommendations as to when one method is more appropriate than another. I will include a discussion of what happens when the SRS does not support or understand the RTP session usage chosen by the SRC. In this light, the turret use case could work in either manner you described; however, multiplexing multiple RTP session with a single m-line would require the definition and negotiation a new multiplexing mechanism, such as BUNDLE or SHIM. I am not planning to provide any details regarding those at this time. We can of course add them if we determine one or the other or both required or recommended for SIPREC. I think it is probably best to wait until you have written what you describe. Then we can discuss if and how it might work for the turret case, which is especially unusual. Thanks, Paul > Cheers, > Charles > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Wednesday, July 11, 2012 10:25 AM >> To: siprec@ietf.org >> Subject: Re: [siprec] proposed update to RTP handling section of protocol >> draft >> >> Charles, >> >> Ram and Partha and I were just discussing the BT "turret" use case. In >> this case they want to record a "mix" of media from multiple independent >> CS media streams onto a single RS m-line. (I guess this is an optimization.) >> >> When doing this, there is a choice of how to do the "mix". It could be >> just running multiple independent RTP streams over the single RTP >> session. Or it could be a real mix, with a single SSRC and one or >> several CSRCs. >> >> I don't know what we want to say about this, or where it ought to go. >> But if we don't say something, somewhere, I doubt that there would be >> much chance of interoperability. >> >> Thanks, >> Paul >> >> On 7/11/12 1:13 PM, Charles Eckel (eckelcu) wrote: >>> I am in the process of updating the RTP handling section (section 7) of the >> protocol draft. Per the consensus at IETF 83, the changes include expanding >> the recommendations to cover SIPREC aware UAs and adding a section on >> RTP session usage by the SRC to deliver media streams to the SRS (e.g. using >> multiple m-lines, SSRC multiplexing, mixing). >>> In doing so, it seems best to me to rearrange the sections as follows: >>> >>> 7. RTP Handling >>> 7.1 RTP Mechanisms >>> 7.1.1 - 7.1.9 (previously sections 7.2 - 7.9 in version 05 of draft) >>> 7.2 Roles (previously section 7.1 in version 05 of draft) >>> 7.3 Examples of RTP Usage by SRC (new, based on IETF 83 presentation) >>> 7.3.1 Multiple m-lines >>> 7.3.2 SSRC Multiplexing >>> 7.3.3 Mixing >>> >>> Please let me know if you have any concerns or alternate suggestions. >>> >>> Cheers, >>> Charles >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > From rbarnes@bbn.com Thu Jul 12 13:24: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 4548821F85AA for ; Thu, 12 Jul 2012 13:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.596 X-Spam-Level: X-Spam-Status: No, score=-106.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 f2jC0RspsrMn for ; Thu, 12 Jul 2012 13:24:01 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 74DE721F8596 for ; Thu, 12 Jul 2012 13:24:01 -0700 (PDT) Received: from ros-dhcp192-1-51-20.bbn.com ([192.1.51.20]:50332) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SpPwB-000Ek4-0K; Thu, 12 Jul 2012 16:24:35 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <07465C1D981ABC41A344374066AE1A2C3A9036B0EA@TLVMBX01.nice.com> Date: Thu, 12 Jul 2012 16:24:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8D2C1F31-31A3-4C4F-A6B0-FC493FD718ED@bbn.com> References: <657A3659-61DB-433A-97F4-593ECD31DB1B@bbn.com> <07465C1D981ABC41A344374066AE1A2C3A9036B0EA@TLVMBX01.nice.com> To: Leon Portman X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Thu, 12 Jul 2012 13:27:57 -0700 Cc: "siprec@ietf.org" Subject: Re: [siprec] Security review of draft-ietf-siprec-protocol-05 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, 12 Jul 2012 20:24:02 -0000 Couple of responses inline. On Jul 3, 2012, at 2:28 AM, Leon Portman wrote: > Richard Hi >=20 > Thank you very much for the review. It is very helpful. Please see = below my answers. >=20 > Leon >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On = Behalf Of Richard L. Barnes > Sent: Thursday, June 28, 2012 6:58 PM > To: siprec@ietf.org > Subject: [siprec] Security review of draft-ietf-siprec-protocol-05 >=20 > Dear SIPREC, >=20 > At the SIPREC meeting at the last IETF, I volunteered to do a security = review of the SIPREC protocol document. Thanks to the chairs = increasingly persistent reminders, I've finally gotten around to doing = it :) >=20 > At one level, my basic question is: How is this better than just doing = a PCAP? I can see the efficiency gains in terms of RTP handling, but = I'm concerned that (1) the security requirements need to be more tightly = specified, and (2) there seems to be quite a bit of information loss. > [LeonP] PCAP method (passive sniffing) requires usage of SPAN ports in = order to forward RTP traffic towards recording system. It used to be = popular method of recording but now Enterprises prefer active methods = for following reasons: less configuration overhead, support for remote = recording systems, better security, support for selective recording etc. = I agree on some level of information loss but we do plan to support = different extension of metadata so all additional information still can = be captured. >=20 > Starting with the most obvious part: The Security Considerations needs = to be tightened up. This document benefits from the fact that the SRC = and the SRS are logically within the same administrative domain, so it = should be feasible to establish credentials that they use to = authenticate one another. So the document should REQUIRE that the SRC = and the SRS mutually authenticate to one another, either using SIP = authentication or using TLS authentication beneath SIPS. > [LeonP] Agree >=20 > At the media level, is there a reason that you don't specify a keying = mechanism? Why would you not just specify DTLS-SRTP? It may also be = worth noting that because this protocol will tend to be used within an = administrative domain, the need for confidentiality is lower than in the = general Internet; however, there is still a strong need for = authentication. So this document should REQUIRE that implementations = support the SRTP_NULL_HMAC_SHA1_* protection profiles and RECOMMEND = support for others. > [LeonP] Actually we wanted to support all standard keying mechanisms. = However because SIPREC media session is established in parallel to the = actual communication session, we want to prefer to use keying mechanism = with fastest session negotiation time in order to minimize lost of = recoding (media clipping). DTLS-SRTP is problematic from this point of = view. Well, you could buffer to prevent clipping, of course, since this isn't = actually real-time. =20 In any case, with TLS session resumption, you can amortize the cost of = TLS negotiation across a long period of time. > Speaking of SRTP, it's not clear whether there's a requirement for the = SRC/SRS to have access to the keys used to protect secure media, in the = case where the SRC is a middlebox, not terminating media. To support = this case, you would need (1) a way to get the key from the endpoint to = the SRC, and (2) a way to get the key from the SRC ot the SRS. I would = suggest looking at EKT / KTR for both of these = [http://tools.ietf.org/html/draft-mcgrew-srtp-ekt-06#section-4][http://too= ls.ietf.org/html/draft-wing-avt-dtls-srtp-key-transport-03]. > [LeonP] Our assumption was that it is out of scope of this work how = SRC will get keys. We used to have text about it and it was removed. We = should discuss it little more. >=20 > Finally, it seems like a gap that the SIP signaling information for = the recorded session doesn't get passed off to the SRC. Section 8 of = the current document describes how to pass "metadata", but doesn't = really define what the metadata is.=20 > [LeonP] We have separate draft for the description of the metadata Sorry, missed the reference.= From eckelcu@cisco.com Thu Jul 12 15:10:51 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 AB9B711E80EE for ; Thu, 12 Jul 2012 15:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.494 X-Spam-Level: X-Spam-Status: No, score=-10.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 EIvUadIf9VHv for ; Thu, 12 Jul 2012 15:10:49 -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 C719111E80CB for ; Thu, 12 Jul 2012 15:10:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=4021; q=dns/txt; s=iport; t=1342131083; x=1343340683; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ov/ihe688W5W5iki8bpHfl2j2MxYwvx0KjnXiVcqRBA=; b=KVlvzantS/SSpPI0RsF7fEu9McZN3Kc14eFrvKnbAcYBtYZDXoMrx6tF vSLvVthKgfL/Lxi9Mf4iinJ4gn4G3GvOSVnMqcv2SfTWZxSG+M2Ymj0tb ciCPresty05Psq+LjI4ju2pyc9zYxk/WI98LTboEUMf9l+EoaEHIeJ9Kd k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALJK/0+tJXG8/2dsb2JhbAA/Bg64CIEHgiABAQEDAQEBAQ8BJzQLDAQCAQgOAwQBAQEKFAkHJwsUCQgBAQQOBQgah2UFAQudYaAIBItAJoR2YAOjWoFmgiY5 X-IronPort-AV: E=Sophos;i="4.77,576,1336348800"; d="scan'208";a="101396214" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 12 Jul 2012 22:11:23 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6CMBMPC016918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Jul 2012 22:11:22 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.205]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0298.004; Thu, 12 Jul 2012 17:11:20 -0500 From: "Charles Eckel (eckelcu)" To: Paul Kyzivat Thread-Topic: [siprec] proposed update to RTP handling section of protocol draft Thread-Index: Ac1fiHQe8s1eJCUpQ9GCasGJMmIjjQAK3/QAAACXQSAAC7QFgAAla1gw Date: Thu, 12 Jul 2012 22:11:20 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882803B7DA@xmb-aln-x08.cisco.com> References: <92B7E61ADAC1BB4F941F943788C0882803A403@xmb-aln-x08.cisco.com> <4FFDB6D4.7010609@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C0882803AEED@xmb-aln-x08.cisco.com> <4FFE0955.6060609@alum.mit.edu> In-Reply-To: <4FFE0955.6060609@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.122.35] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19036.000 x-tm-as-result: No--63.976100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] proposed update to RTP handling section of protocol draft 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, 12 Jul 2012 22:10:51 -0000 Sounds good. The text I am adding, particularly that for SSRC multiplexing,= makes several assumptions. It will be helpful to tear into those. My goal = is for the text to help facilitate those discussions. Cheers, Charles =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Wednesday, July 11, 2012 4:17 PM > To: Charles Eckel (eckelcu) > Cc: siprec@ietf.org > Subject: Re: [siprec] proposed update to RTP handling section of protocol > draft >=20 > On 7/11/12 6:48 PM, Charles Eckel (eckelcu) wrote: > > Hi Paul, > > > > My current plan is to provide examples in which an SRC uses multiple m- > lines, SSRC multiplexing, or mixing, without making an explicitly > recommendations as to when one method is more appropriate than > another. I will include a discussion of what happens when the SRS does no= t > support or understand the RTP session usage chosen by the SRC. In this > light, the turret use case could work in either manner you described; > however, multiplexing multiple RTP session with a single m-line would > require the definition and negotiation a new multiplexing mechanism, such > as BUNDLE or SHIM. I am not planning to provide any details regarding tho= se > at this time. We can of course add them if we determine one or the other = or > both required or recommended for SIPREC. >=20 > I think it is probably best to wait until you have written what you > describe. Then we can discuss if and how it might work for the turret > case, which is especially unusual. >=20 > Thanks, > Paul >=20 > > Cheers, > > Charles > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > >> Of Paul Kyzivat > >> Sent: Wednesday, July 11, 2012 10:25 AM > >> To: siprec@ietf.org > >> Subject: Re: [siprec] proposed update to RTP handling section of proto= col > >> draft > >> > >> Charles, > >> > >> Ram and Partha and I were just discussing the BT "turret" use case. In > >> this case they want to record a "mix" of media from multiple > independent > >> CS media streams onto a single RS m-line. (I guess this is an > optimization.) > >> > >> When doing this, there is a choice of how to do the "mix". It could be > >> just running multiple independent RTP streams over the single RTP > >> session. Or it could be a real mix, with a single SSRC and one or > >> several CSRCs. > >> > >> I don't know what we want to say about this, or where it ought to go. > >> But if we don't say something, somewhere, I doubt that there would be > >> much chance of interoperability. > >> > >> Thanks, > >> Paul > >> > >> On 7/11/12 1:13 PM, Charles Eckel (eckelcu) wrote: > >>> I am in the process of updating the RTP handling section (section 7) = of > the > >> protocol draft. Per the consensus at IETF 83, the changes include > expanding > >> the recommendations to cover SIPREC aware UAs and adding a section on > >> RTP session usage by the SRC to deliver media streams to the SRS (e.g. > using > >> multiple m-lines, SSRC multiplexing, mixing). > >>> In doing so, it seems best to me to rearrange the sections as follows= : > >>> > >>> 7. RTP Handling > >>> 7.1 RTP Mechanisms > >>> 7.1.1 - 7.1.9 (previously sections 7.2 - 7.9 in version 05 of draft) > >>> 7.2 Roles (previously section 7.1 in version 05 of draft) > >>> 7.3 Examples of RTP Usage by SRC (new, based on IETF 83 presentation) > >>> 7.3.1 Multiple m-lines > >>> 7.3.2 SSRC Multiplexing > >>> 7.3.3 Mixing > >>> > >>> Please let me know if you have any concerns or alternate suggestions. > >>> > >>> Cheers, > >>> Charles > >>> _______________________________________________ > >>> siprec mailing list > >>> siprec@ietf.org > >>> https://www.ietf.org/mailman/listinfo/siprec > >>> > >> > >> _______________________________________________ > >> siprec mailing list > >> siprec@ietf.org > >> https://www.ietf.org/mailman/listinfo/siprec > > From internet-drafts@ietf.org Fri Jul 13 13:32:14 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 86ADC11E80C8; Fri, 13 Jul 2012 13:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 5xcw8Rna3D4k; Fri, 13 Jul 2012 13:32:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F6811E8102; Fri, 13 Jul 2012 13:32:13 -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.30p3 Message-ID: <20120713203213.25563.37994.idtracker@ietfa.amsl.com> Date: Fri, 13 Jul 2012 13:32:13 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-protocol-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: Fri, 13 Jul 2012 20:32:14 -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 IETF. Title : Session Recording Protocol Author(s) : Leon Portman Henry Lum Charles Eckel Alan Johnston Andrew Hutton Filename : draft-ietf-siprec-protocol-06.txt Pages : 40 Date : 2012-07-13 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-siprec-protocol-06 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-protocol-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From eckelcu@cisco.com Fri Jul 13 13:42: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 7BEFB11E810A for ; Fri, 13 Jul 2012 13:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.503 X-Spam-Level: X-Spam-Status: No, score=-10.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 kFBAPkp4Lj-C for ; Fri, 13 Jul 2012 13:42:22 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B1AAC11E80C7 for ; Fri, 13 Jul 2012 13:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2290; q=dns/txt; s=iport; t=1342212180; x=1343421780; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=PFL+fPFuOhgaPWU89qHchNJrdaQLt3oVsxrARujJhu0=; b=jvjFayI6is8VYnj+4AVjhC9o7ZImYKrAK9rXRUXGPCPKKjesTIkrX/4U yplNZYYtONal2rkGa+yF8+kXJlNQ7BqdXkvSqwmAykxKLyhbCrRsFiBY4 yX9kslKDFBovylWf+Rn4i45avabtppeQte8m+NNRw3u3JTZl2YwEsVQpn A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGWHAFCtJV2c/2dsb2JhbABFuB+BB4IgAQEBBAEBAQ8BJzQXBAIBCBEEAQELFAkHJwsUCQgCBBMIARmHagELm12gKIs8GoR8YAOWTI0OgWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,580,1336348800"; d="scan'208";a="101737746" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 13 Jul 2012 20:42:59 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6DKgw0s011088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 13 Jul 2012 20:42:59 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.205]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0298.004; Fri, 13 Jul 2012 15:42:58 -0500 From: "Charles Eckel (eckelcu)" To: "siprec@ietf.org" Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-protocol-06.txt Thread-Index: AQHNYTa6aWZdzPLEHUSYzHk3HDKznZcnrLVg Date: Fri, 13 Jul 2012 20:42:58 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882803BE3E@xmb-aln-x08.cisco.com> References: <20120713203213.25563.37994.idtracker@ietfa.amsl.com> In-Reply-To: <20120713203213.25563.37994.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.122.35] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19038.001 x-tm-as-result: No--34.759300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No 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-protocol-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: Fri, 13 Jul 2012 20:42:23 -0000 This update incorporates the RTP handling changes as posted previously on t= his list: http://www.ietf.org/mail-archive/web/siprec/current/msg03290.html The only additional changes are those resulting from spellcheck and idnits. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of internet-drafts@ietf.org > Sent: Friday, July 13, 2012 1:32 PM > To: i-d-announce@ietf.org > Cc: siprec@ietf.org > Subject: [siprec] I-D Action: draft-ietf-siprec-protocol-06.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 : Session Recording Protocol > Author(s) : Leon Portman > Henry Lum > Charles Eckel > Alan Johnston > Andrew Hutton > Filename : draft-ietf-siprec-protocol-06.txt > Pages : 40 > Date : 2012-07-13 >=20 > Abstract: > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-siprec-protocol-06 >=20 > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-protocol-06 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Tue Jul 17 03:32: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 8FE1621F86F1 for ; Tue, 17 Jul 2012 03:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 B0cQlAAMHVna for ; Tue, 17 Jul 2012 03:32:45 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id D7A2321F86EB for ; Tue, 17 Jul 2012 03:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=2084; q=dns/txt; s=iport; t=1342521205; x=1343730805; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=hXp90x6Wi5NKTK5RLg+6y06BGvBFtW42+DYF6OJe6fc=; b=QehzNJGXGnVFHa5cRIwrOmr+Qp4USyr+vzJhgVIcmH66+D2ERRxhUwda yfFpr0Ulyoitb0hp7M9afIr7UBxudvd2NXr+2DeYGZ3zCmQ9VTGmrp5wn 2XyfV2vb16r8jx6kKVdHdozMQWgbwhV/+MlxdPK/+/xayxXs+4eT61OPi A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIQ+BVCtJXG+/2dsb2JhbABFuU6BB4InEgEnUQE+QicEEwkZh2sLmxyBKKArkgcDlT2JKIR6gWaCXw X-IronPort-AV: E=Sophos;i="4.77,601,1336348800"; d="scan'208";a="102596713" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 17 Jul 2012 10:33:24 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6HAXOMp014460 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 17 Jul 2012 10:33:24 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.114]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0298.004; Tue, 17 Jul 2012 05:33:24 -0500 From: "Ram Mohan R (rmohanr)" To: "siprec@ietf.org" Thread-Topic: Regarding XML element having "session_id" as attribute Thread-Index: AQHNZAeXU1POXyJ61USOtD62+kAB9A== Date: Tue, 17 Jul 2012 10:33:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [173.39.68.77] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19046.000 x-tm-as-result: No--38.588800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Regarding XML element having "session_id" as attribute 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, 17 Jul 2012 10:32:46 -0000 Hi all, In the current draft [ draft-ietf-siprec-metadata-07] the schema is defined in such a way that each instance of XML element MUST have "session_id" as attribute. Per the agreement we had in IETF82 ( Look at Issue 1 in the minutes of http://www.ietf.org/proceedings/82/minutes/siprec.txt), we can have use-cases where a participant need not be associated with a CS. So we agreed that the attributes of are common and independent of session. Any attribute of participant that is scoped to a session has to be listed in XML element. By going this way we don't need to have session_id as attribute. The above change is already reflected in the metadata model but the schema still shows session_id as attribute for which is inconsistent/wrong. So we will have to change the schema to reflect the above and the new schema for that portion will look as: A Instance would look like (note I have shown for the sake of completeness) : participant participant_id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> Paul 2010-12-16T23:41:07Z Let me know in case some one has issues with the above change. If not we will make this change in the next revision. Regards, Ram From andrew.hutton@siemens-enterprise.com Tue Jul 17 05:44: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 3DAAE21F8628 for ; Tue, 17 Jul 2012 05:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 RXsVJ9So+L2Z for ; Tue, 17 Jul 2012 05:44:08 -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 C633121F86B0 for ; Tue, 17 Jul 2012 05:44:07 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 109C123F05C1; Tue, 17 Jul 2012 14:44:52 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.131]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0309.002; Tue, 17 Jul 2012 14:44:51 +0200 From: "Hutton, Andrew" To: Michael Smith , "siprec@ietf.org" Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-metadata-07.txt Thread-Index: AQHNWOGW2wZyYKdvMkemVVUMYzwTFZcW86SAgAoMM+D//+c9gIAMmWMA Date: Tue, 17 Jul 2012 12:44:51 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF056C78@MCHP04MSX.global-ad.net> References: <20120703060324.32593.96953.idtracker@ietfa.amsl.com> <9F33F40F6F2CD847824537F3C4E37DDF043651@MCHP04MSX.global-ad.net> <05D56509F27CCE4DAF8136C02386880D68647287@exc01.dss.lan> In-Reply-To: <05D56509F27CCE4DAF8136C02386880D68647287@exc01.dss.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-07.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, 17 Jul 2012 12:44:09 -0000 Hi Michael, Thanks for volunteering to review this draft and sorry it took so long for = me to respond. Yes the link you indicated below will point you at the right version. It is great to know that NENA are interested in our work. Any chance you will be in Vancouver for IETF84 or if not maybe you can join= the session remotely? Also it would be great to have your comments anytime but if you could make = it before the IETF84 meeting then we could discuss any issues raised there. Regards Andy (SIPREC Co-Chair). > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Michael Smith > Sent: 09 July 2012 15:15 > To: siprec@ietf.org > Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-07.txt >=20 > Andy, >=20 > I volunteer to do a review; is this the correct version: > https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/ ? >=20 > Note: I'll limit my comments to basic editorial stuff, and things I'm > pretty sure are real issues, since I've only recently become familiar > with SIPREC and don't want to waste your time on things I simply don't > understand. BTW, Brian Rosen knows me from NENA work. I'm on his LTD > working group, and lead the NG9-1-1 PSAP working group, and the > recording test committee. We've proposed using SIPREC as the media > recording protocol in NG9-1-1. >=20 > Reviewing this draft will help me understand better, and hopefully > provide some usable feedback to you. >=20 > Regards, >=20 > Michael Smith > Chief Technologist > Ph: 606.877.2788 | Mobile: 606.231.0243 >=20 > DSS Corporation / Equature > 18311=A0=A0 W. Ten Mile Road, Suite 200 > Southfield, MI - 48075 > Tel: 1-888.305.3428 > Fax: 1-248.569.6567 > www.dss-corp.com > www.dispatchimprovement.com >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: Monday, July 09, 2012 9:46 AM > To: siprec@ietf.org > Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-07.txt >=20 > Hi All, >=20 > We need a few volunteers to do a full review of the SIPREC metadata > draft. >=20 > If you are able to volunteer for this please let me know. >=20 > If we could have some people review the draft before IETF84 then that > would be perfect. >=20 > Regards > Andy (SIPREC Co-Chair). >=20 >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Ram Mohan R (rmohanr) > > Sent: 03 July 2012 07:17 > > To: internet-drafts@ietf.org; i-d-announce@ietf.org > > Cc: siprec@ietf.org > > Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-07.txt > > > > Hi all, > > > > This version of the draft tries the incorporate the comments received > > in IETF 83 Refer to > > http://www.ietf.org/proceedings/83/minutes/minutes-83- > > siprec.pdf > > for the minutes. > > > > To summarize it has following changes: > > 1) Incorporated start/stop times for CS > > 2) Edits to CSRS association and ParticipantCSAssociation > > 3) Minor NITS received as comments in previous version > > 4) Modified the XML to have id as just id instead of group_id e.t.c > > and session instead of session_id. > > 5) Modified the examples to reflect the change in schema in [4] > > > > Please review the draft and provide your comments. > > > > Authors > > > > On 03/07/12 11:33 AM, "internet-drafts@ietf.org" > > wrote: > > > > > > > >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-07.txt > > > Pages : 48 > > > Date : 2012-07-02 > > > > > >Abstract: > > > Session recording is a critical requirement in many > communications > > > environments such as call centers and financial trading. In some > > of > > > these environments, all calls must be recorded for regulatory, > > > compliance, and consumer protection reasons. Recording of a > > session > > > is typically performed by sending a copy of a media stream to a > > > recording device. This document describes the metadata model as > > > viewed by Session Recording Server(SRS) and the Recording > metadata > > > format. > > > > > > > > >The IETF datatracker status page for this draft is: > > >https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata > > > > > >There's also a htmlized version available at: > > >http://tools.ietf.org/html/draft-ietf-siprec-metadata-07 > > > > > >A diff from previous version is available at: > > >http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-metadata-07 > > > > > > > > >Internet-Drafts are also available by anonymous FTP at: > > >ftp://ftp.ietf.org/internet-drafts/ > > > > > >_______________________________________________ > > >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 Jul 17 05:49: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 A4D5221F86C4 for ; Tue, 17 Jul 2012 05:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 N2foTFww8sxw for ; Tue, 17 Jul 2012 05:49:01 -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 DFE0921F85D4 for ; Tue, 17 Jul 2012 05:49:00 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id F347723F05C9 for ; Tue, 17 Jul 2012 14:49:47 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.131]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0309.002; Tue, 17 Jul 2012 14:49:46 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: I-D Action: draft-ram-siprec-callflows-01.txt Thread-Index: AQHNY5D1UVDMV8cmgkSYreVRJ9hppZctbgyw Date: Tue, 17 Jul 2012 12:49:45 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF056CA0@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] FW: I-D Action: draft-ram-siprec-callflows-01.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, 17 Jul 2012 12:49:02 -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: 16 July 2012 21:23 To: i-d-announce@ietf.org Subject: I-D Action: draft-ram-siprec-callflows-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Session Initiation Protocol (SIP) Recording Call Flows Author(s) : Ram Mohan Ravindranath Parthasarathi Ravindran Paul Kyzivat Filename : draft-ram-siprec-callflows-01.txt Pages : 20 Date : 2012-07-16 Abstract: Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document lists call flows that has snapshot of metadata sent from SRC to SRS, the metadata format for which is described in [I-D.ietf-siprec-metadata] . This is purely an informational document that is written to support the model defined the metadata draft. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ram-siprec-callflows There's also a htmlized version available at: http://tools.ietf.org/html/draft-ram-siprec-callflows-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ram-siprec-callflows-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 Tue Jul 17 05:53: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 ECCD721F86E0 for ; Tue, 17 Jul 2012 05:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 flNZ08FXrxbj for ; Tue, 17 Jul 2012 05:53:40 -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 066C321F8621 for ; Tue, 17 Jul 2012 05:53:40 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id EE0B323F05B9; Tue, 17 Jul 2012 14:54:22 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.131]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0309.002; Tue, 17 Jul 2012 14:54:22 +0200 From: "Hutton, Andrew" To: "Ram Mohan R (rmohanr)" , Paul Kyzivat , "pravindran@sonusnet.com" Thread-Topic: I-D Action: draft-ram-siprec-callflows-01.txt Thread-Index: AQHNY5D1UVDMV8cmgkSYreVRJ9hppZctbkIg Date: Tue, 17 Jul 2012 12:54:21 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF056CDE@MCHP04MSX.global-ad.net> References: <20120716202259.26064.18454.idtracker@ietfa.amsl.com> In-Reply-To: <20120716202259.26064.18454.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] I-D Action: draft-ram-siprec-callflows-01.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, 17 Jul 2012 12:53:41 -0000 Hi All, Thanks for submitting this draft I think it will be helpful. I assume it is your intention to ask the working group to adopt this correc= t? Do you want to present this at IETF84? Regards Andy > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: 16 July 2012 21:23 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-ram-siprec-callflows-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : Session Initiation Protocol (SIP) Recording > Call Flows > Author(s) : Ram Mohan Ravindranath > Parthasarathi Ravindran > Paul Kyzivat > Filename : draft-ram-siprec-callflows-01.txt > Pages : 20 > Date : 2012-07-16 >=20 > Abstract: > Session recording is a critical requirement in many communications > environments such as call centers and financial trading. In some of > these environments, all calls must be recorded for regulatory, > compliance, and consumer protection reasons. Recording of a session > is typically performed by sending a copy of a media stream to a > recording device. This document lists call flows that has snapshot > of metadata sent from SRC to SRS, the metadata format for which is > described in [I-D.ietf-siprec-metadata] . This is purely an > informational document that is written to support the model defined > the metadata draft. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ram-siprec-callflows >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ram-siprec-callflows-01 >=20 > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ram-siprec-callflows-01 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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 Tue Jul 17 06:45: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 22FCD21F86D9 for ; Tue, 17 Jul 2012 06:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 Ft1Su8UfYVjJ for ; Tue, 17 Jul 2012 06:45:39 -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 77B7021F86E3 for ; Tue, 17 Jul 2012 06:45:39 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 214271EB8451 for ; Tue, 17 Jul 2012 15:46:26 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.131]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0309.002; Tue, 17 Jul 2012 15:46:25 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: IETF84 SIPREC Agenda Thread-Index: Ac1kIo56JHpqvI/ZT2W7QTAqYsjFGw== Date: Tue, 17 Jul 2012 13:46:25 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF056D84@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] IETF84 SIPREC 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, 17 Jul 2012 13:45:40 -0000 Hi All, A draft agenda can be found at: http://www.ietf.org/proceedings/84/agenda/a= genda-84-siprec.=20 Can those listed (Leon, Henry, Partha, Hadriel?) as presenting please confi= rm with me that they are ok with the time allocated and start to prepare yo= ur slides. Please try to provide slides before travelling to Vancouver. Regards Andy From Leon.Portman@nice.com Tue Jul 17 07:16: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 3E52021F8665 for ; Tue, 17 Jul 2012 07:16:21 -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=[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 UXRH9be3srpa for ; Tue, 17 Jul 2012 07:16:20 -0700 (PDT) Received: from mailil.nice.com (mailil.nice.com [192.114.148.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4BA21F853B for ; Tue, 17 Jul 2012 07:16:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,603,1336338000"; d="scan'208";a="3487275" Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Tue, 17 Jul 2012 17:17:04 +0300 From: Leon Portman To: "Hutton, Andrew" , "siprec@ietf.org" Date: Tue, 17 Jul 2012 17:17:03 +0300 Thread-Topic: IETF84 SIPREC Agenda Thread-Index: Ac1kIo56JHpqvI/ZT2W7QTAqYsjFGwAA+FeQ Message-ID: <07465C1D981ABC41A344374066AE1A2C3AB0FBDDAF@TLVMBX01.nice.com> References: <9F33F40F6F2CD847824537F3C4E37DDF056D84@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF056D84@MCHP04MSX.global-ad.net> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] IETF84 SIPREC 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, 17 Jul 2012 14:16:21 -0000 Looking good Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Hutton, Andrew Sent: Tuesday, July 17, 2012 4:46 PM To: siprec@ietf.org Subject: [siprec] IETF84 SIPREC Agenda Hi All, A draft agenda can be found at: http://www.ietf.org/proceedings/84/agenda/a= genda-84-siprec.=20 Can those listed (Leon, Henry, Partha, Hadriel?) as presenting please confi= rm with me that they are ok with the time allocated and start to prepare yo= ur slides. Please try to provide slides before travelling to Vancouver. Regards Andy _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From pravindran@sonusnet.com Tue Jul 17 11:40: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 6404321F86B4 for ; Tue, 17 Jul 2012 11:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 BMHvJXFY6arm for ; Tue, 17 Jul 2012 11:40:49 -0700 (PDT) Received: from na3sys010aog114.obsmtp.com (na3sys010aog114.obsmtp.com [74.125.245.96]) by ietfa.amsl.com (Postfix) with ESMTP id 4350D21F8686 for ; Tue, 17 Jul 2012 11:40:49 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob114.postini.com ([74.125.244.12]) with SMTP ID DSNKUAWx4eG+2MXRQQwzDPtkQADBVPwEGoEn@postini.com; Tue, 17 Jul 2012 11:41: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; Tue, 17 Jul 2012 14:41:35 -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, 18 Jul 2012 00:11:33 +0530 From: "Ravindran, Parthasarathi" To: "Hutton, Andrew" , "Ram Mohan R (rmohanr)" , Paul Kyzivat Thread-Topic: I-D Action: draft-ram-siprec-callflows-01.txt Thread-Index: AQHNY5D1UVDMV8cmgkSYreVRJ9hppZctbkIggABaQkA= Date: Tue, 17 Jul 2012 18:41:32 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C16060A00@inba-mail01.sonusnet.com> References: <20120716202259.26064.18454.idtracker@ietfa.amsl.com> <9F33F40F6F2CD847824537F3C4E37DDF056CDE@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF056CDE@MCHP04MSX.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] I-D Action: draft-ram-siprec-callflows-01.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, 17 Jul 2012 18:40:50 -0000 Hi Andy, Thanks for forwarding (-01) draft to WG alias and providing the slot in SIP= REC. As we mentioned in -00 draft mail, this draft is created for informal = purpose of SIPREC metadata usage. Let us discuss whether the content of the= draft has to be tracked as a separate deliverable or shall be added in Sec= 13 of metadata (Appendix B) draft itself.=20 Could you please include my name as a IETF-84 presenter for this draft. Hi all, The update between -00 and -01 version of the draft are 1) Group element removal for the usecase wherein the single session only ex= ists. 2) Removal of extension information like call-Center to focus on defined me= tadata specific XML elements. 3) Examples are changed with example.com FQDN. 4) Correction in Example 5 (turret usecase) unique-id usage 5) Paul Kyzivat Affiliation change Thanks Partha >-----Original Message----- >From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] >Sent: Tuesday, July 17, 2012 6:24 PM >To: Ram Mohan R (rmohanr); Paul Kyzivat; Ravindran, Parthasarathi >Cc: siprec@ietf.org >Subject: RE: I-D Action: draft-ram-siprec-callflows-01.txt > >Hi All, > >Thanks for submitting this draft I think it will be helpful. > >I assume it is your intention to ask the working group to adopt this >correct? > >Do you want to present this at IETF84? > >Regards >Andy > > > >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- >> bounces@ietf.org] On Behalf Of internet-drafts@ietf.org >> Sent: 16 July 2012 21:23 >> To: i-d-announce@ietf.org >> Subject: I-D Action: draft-ram-siprec-callflows-01.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Session Initiation Protocol (SIP) Recording >> Call Flows >> Author(s) : Ram Mohan Ravindranath >> Parthasarathi Ravindran >> Paul Kyzivat >> Filename : draft-ram-siprec-callflows-01.txt >> Pages : 20 >> Date : 2012-07-16 >> >> Abstract: >> Session recording is a critical requirement in many communications >> environments such as call centers and financial trading. In some >of >> these environments, all calls must be recorded for regulatory, >> compliance, and consumer protection reasons. Recording of a >session >> is typically performed by sending a copy of a media stream to a >> recording device. This document lists call flows that has snapshot >> of metadata sent from SRC to SRS, the metadata format for which is >> described in [I-D.ietf-siprec-metadata] . This is purely an >> informational document that is written to support the model defined >> the metadata draft. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ram-siprec-callflows >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ram-siprec-callflows-01 >> >> A diff from previous version is available at: >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ram-siprec-callflows-01 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 eckelcu@cisco.com Thu Jul 19 15:42: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 4771411E80A6 for ; Thu, 19 Jul 2012 15:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.896 X-Spam-Level: X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[AWL=-0.497, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=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 aQkJ5OYyTEMo for ; Thu, 19 Jul 2012 15:42:34 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 478F911E80A2 for ; Thu, 19 Jul 2012 15:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=3024; q=dns/txt; s=iport; t=1342737809; x=1343947409; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=hUQCKSQMGcgVvOdWtasQmK8GN4dzCstFbe7F3mThCYg=; b=blqIuC+YoBzVcNlie7vD9RwP7SiiBwwXO2DyUwGenwtrWMiSzK6Hp+QD 7UqcIGD0gPKEUdHDgQ4FUshO03gshY+ggQCkwA2krI3TBKsbdJz6o5e5b 2Rr2iK98Z5tJjdj/bXHaLr5KBReuHALnwMqGX4+CMlEav8UUbXtg2AlV9 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYIAEiNCFCtJXHA/2dsb2JhbABFhDC1GoEHgiIBBBIBJy4jASoUQiYBBBsah2oBnTqBKKAWkUxgA6NngWaCXw X-IronPort-AV: E=Sophos;i="4.77,618,1336348800"; d="scan'208";a="103593743" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 19 Jul 2012 22:43:28 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6JMhSks017005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 19 Jul 2012 22:43:28 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.205]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0298.004; Thu, 19 Jul 2012 17:43:27 -0500 From: "Charles Eckel (eckelcu)" To: "siprec@ietf.org" Thread-Topic: comments on draft-ietf-siprec-protocol-06 Thread-Index: Ac1l/+S2usiuTbtLTba/unvcA+nRVQ== Date: Thu, 19 Jul 2012 22:43:27 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828042AD2@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.122.35] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19050.003 x-tm-as-result: No--36.628900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] comments on draft-ietf-siprec-protocol-06 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, 19 Jul 2012 22:42:35 -0000 I have one major comment and one minor comment on the draft. I'll start wit= h the major comment. Section 6.1 and section 6.2 discuss the use for the +sip.src/+sip.srs featu= re tag and siprec option tag by a SRC/SRS to start an RS. The section clear= ly and correctly states that both the feature tag and the option tag must b= e present. However, the sections also describe the usage of the +sip.src/+sip.srs feat= ure tags in REGISTSER messages. The usage of +sip.src/+sip.srs feature tag = without the siprec options tag in other requests, such as INVITE, is not co= vered. The meaning of these feature tags to UAs in not addressed. I suggest to change section 6 from "Initiating a Recording" to "SIP Handli= ng". This is more in line with the approach take in sections 7 and 8, which= are titled "SDP Handling" and "RTP Handling". Within section 6 was can ha= ve: 6.1 Procedures at the SRC =20 6.2 Procedures at the SRS 6.3 Procedures at Recording-aware UAs To the existing section 7, we can add: Section 7.3 Procedures at Recording-Aware UAs. The material currently in section 11 gets relocated into section 6 and 7 ac= cordingly. In addition to simply reorganizing, we also clarify what it means for a UA = to receive to INVITE or 200 OK from an SRC that includes +sip.src. I take t= his to mean that the thing the UA is talking to is able to act as a SIPREC = SRC, even though it may not be recording currently. This may be useful in s= ome scenarios, such as for an MCU to know that one of the participants in t= he conference is a recorder. Consequently the UA or MCU may want to indicat= e a recording preference, and/or pay attention to any SDP record attributes= . Whether or not the UA/MCU can influence the operation of the SRC remains = a policy decision of the SRC, as currently described in the draft. My minor/editorial comment is in regard to section 5.3. This section provid= es good introductory information; however, the first paragraph does not rea= d well in my opinion. I think it would benefit from separating the record a= nd recordpref attributes discussion a bit. Proposed text is as follows: "The SRC is responsible for providing recording indications to the particip= ants in the CS. The SRC does so using the SIPREC defined SDP attribute a=3D= record. This attribute is used as a declaration by the SRC to indicate whet= her recording of the CS is taking place . The SRC may use other recording i= ndication mechanisms as well; however, such mechanisms are outside the scop= e of SIPREC. Recording-aware UAs can indicate a recording preference in the CS using the= SIPREC defined SDP attribute a=3Drecordpref. The recording preference attr= ibute is a declaration by the recording-aware UA of its recording preferenc= e. The SRC is not obligated to honor a recording preference provided by a U= A, as it is merely an indication of a preference, not a direct command or r= equest to start or stop recording." Cheers, Charles From pravindran@sonusnet.com Sun Jul 22 20:10: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 AF87F21F8699 for ; Sun, 22 Jul 2012 20:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 Y2ZDka6vJMYx for ; Sun, 22 Jul 2012 20:10:58 -0700 (PDT) Received: from na3sys010aog114.obsmtp.com (na3sys010aog114.obsmtp.com [74.125.245.96]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC6221F856C for ; Sun, 22 Jul 2012 20:10:58 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob114.postini.com ([74.125.244.12]) with SMTP ID DSNKUAzAwYXEYVOaSqmW1ReybcC4IxPNT/Lj@postini.com; Sun, 22 Jul 2012 20:10:58 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.309.2; Sun, 22 Jul 2012 23:10:56 -0400 Received: from INBA-MAIL02.sonusnet.com ([fe80::f8d4:7090:f632:bbbc]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.02.0298.004; Mon, 23 Jul 2012 08:40:54 +0530 From: "Ravindran, Parthasarathi" To: "Ram Mohan R (rmohanr)" Thread-Topic: Editorial review comment in Metadata draft Thread-Index: Ac1ogNxoAWfXFhqhSY25AEIrz8T/mA== Date: Mon, 23 Jul 2012 03:10:52 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C2BA271EF@inba-mail02.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 Cc: "siprec@ietf.org" Subject: [siprec] Editorial review comment in Metadata draft 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, 23 Jul 2012 03:10:59 -0000 Hi Ram, I noticed that the following editorial review comments in the (-07) of meta= data draft 1) CSRSAssociation metadata block is not added in the metadata model wherea= s it is explained in Sec 6.4 2) Removal of csrc element in stream to make the schema inline with stream = metadata attributes 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 C8CEE21F8491 for ; Mon, 23 Jul 2012 06:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 ulTtk9I72fQc for ; Mon, 23 Jul 2012 06:34:54 -0700 (PDT) Received: from spam.dss-corp.com (spam.dss-corp.com [67.214.118.46]) by ietfa.amsl.com (Postfix) with ESMTP id 86CB321F848F for ; Mon, 23 Jul 2012 06:34:54 -0700 (PDT) Received: from spam.dss-corp.com (127.0.0.1) by spam.dss-corp.com (MlfMTA v3.2r9) id h1laa80171sm for ; Mon, 23 Jul 2012 09:41:54 -0400 (envelope-from ) Received: from exc.dss-corp.com ([192.168.1.5]) by spam.dss-corp.com (SonicWALL 7.2.4.3929) with ESMTP; Mon, 23 Jul 2012 09:41:54 -0400 Received: from EXC01.dss.lan ([fe80::109b:ad4:1a47:2813]) by exc01.dss.lan ([fe80::109b:ad4:1a47:2813%13]) with mapi; Mon, 23 Jul 2012 09:34:54 -0400 From: Michael Smith To: "Hutton, Andrew" , "siprec@ietf.org" Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-metadata-07.txt Thread-Index: AQHNWOGZ1iutGtCPoUO5Vodq+FzB9JcXWDqAgAnrRgD//8LLgIAMvumAgAk4mZA= Date: Mon, 23 Jul 2012 13:34:51 +0000 Message-ID: <05D56509F27CCE4DAF8136C02386880D686ADD1C@exc01.dss.lan> References: <20120703060324.32593.96953.idtracker@ietfa.amsl.com> <9F33F40F6F2CD847824537F3C4E37DDF043651@MCHP04MSX.global-ad.net> <05D56509F27CCE4DAF8136C02386880D68647287@exc01.dss.lan> <9F33F40F6F2CD847824537F3C4E37DDF056C78@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF056C78@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mlf-Version: 7.2.4.3929 X-Mlf-UniqueId: o201207231341540069264 Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-07.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, 23 Jul 2012 13:34:55 -0000 Andy, I can't make the IETF meeting. I didn't know it was possible to join remote= ly, but I'd like to. Is the info for joining remotely on the IETF84 pages? Michael Smith Chief Technologist Ph: 606.877.2788 | Mobile: 606.231.0243=20 DSS Corporation / Equature 18311=A0=A0 W. Ten Mile Road, Suite 200 Southfield, MI - 48075 Tel: 1-888.305.3428 Fax: 1-248.569.6567 www.dss-corp.com www.dispatchimprovement.com -----Original Message----- From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com]=20 Sent: Tuesday, July 17, 2012 8:45 AM To: Michael Smith; siprec@ietf.org Subject: RE: [siprec] I-D Action: draft-ietf-siprec-metadata-07.txt Hi Michael, Thanks for volunteering to review this draft and sorry it took so long for = me to respond. Yes the link you indicated below will point you at the right version. It is great to know that NENA are interested in our work. Any chance you will be in Vancouver for IETF84 or if not maybe you can join= the session remotely? Also it would be great to have your comments anytime but if you could make = it before the IETF84 meeting then we could discuss any issues raised there. Regards Andy (SIPREC Co-Chair). > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Michael Smith > Sent: 09 July 2012 15:15 > To: siprec@ietf.org > Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-07.txt >=20 > Andy, >=20 > I volunteer to do a review; is this the correct version: > https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/ ? >=20 > Note: I'll limit my comments to basic editorial stuff, and things I'm=20 > pretty sure are real issues, since I've only recently become familiar=20 > with SIPREC and don't want to waste your time on things I simply don't=20 > understand. BTW, Brian Rosen knows me from NENA work. I'm on his LTD=20 > working group, and lead the NG9-1-1 PSAP working group, and the=20 > recording test committee. We've proposed using SIPREC as the media=20 > recording protocol in NG9-1-1. >=20 > Reviewing this draft will help me understand better, and hopefully=20 > provide some usable feedback to you. >=20 > Regards, >=20 > Michael Smith > Chief Technologist > Ph: 606.877.2788 | Mobile: 606.231.0243 >=20 > DSS Corporation / Equature > 18311=A0=A0 W. Ten Mile Road, Suite 200 > Southfield, MI - 48075 > Tel: 1-888.305.3428 > Fax: 1-248.569.6567 > www.dss-corp.com > www.dispatchimprovement.com >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Hutton, Andrew > Sent: Monday, July 09, 2012 9:46 AM > To: siprec@ietf.org > Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-07.txt >=20 > Hi All, >=20 > We need a few volunteers to do a full review of the SIPREC metadata=20 > draft. >=20 > If you are able to volunteer for this please let me know. >=20 > If we could have some people review the draft before IETF84 then that=20 > would be perfect. >=20 > Regards > Andy (SIPREC Co-Chair). >=20 >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > > Behalf Of Ram Mohan R (rmohanr) > > Sent: 03 July 2012 07:17 > > To: internet-drafts@ietf.org; i-d-announce@ietf.org > > Cc: siprec@ietf.org > > Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-07.txt > > > > Hi all, > > > > This version of the draft tries the incorporate the comments=20 > > received in IETF 83 Refer to > > http://www.ietf.org/proceedings/83/minutes/minutes-83- > > siprec.pdf > > for the minutes. > > > > To summarize it has following changes: > > 1) Incorporated start/stop times for CS > > 2) Edits to CSRS association and ParticipantCSAssociation > > 3) Minor NITS received as comments in previous version > > 4) Modified the XML to have id as just id instead of group_id e.t.c=20 > > and session instead of session_id. > > 5) Modified the examples to reflect the change in schema in [4] > > > > Please review the draft and provide your comments. > > > > Authors > > > > On 03/07/12 11:33 AM, "internet-drafts@ietf.org" > > wrote: > > > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts=20 > > >directories. > > > This draft is a work item of the SIP Recording Working Group of=20 > > >the > > IETF. > > > > > > Title : Session Initiation Protocol (SIP) Recording > > Metadata > > > Author(s) : Ram Mohan Ravindranath > > > Parthasarathi Ravindran > > > Paul Kyzivat > > > Filename : draft-ietf-siprec-metadata-07.txt > > > Pages : 48 > > > Date : 2012-07-02 > > > > > >Abstract: > > > Session recording is a critical requirement in many > communications > > > environments such as call centers and financial trading. In=20 > > > 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. > > > > > > > > >The IETF datatracker status page for this draft is: > > >https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata > > > > > >There's also a htmlized version available at: > > >http://tools.ietf.org/html/draft-ietf-siprec-metadata-07 > > > > > >A diff from previous version is available at: > > >http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-metadata-07 > > > > > > > > >Internet-Drafts are also available by anonymous FTP at: > > >ftp://ftp.ietf.org/internet-drafts/ > > > > > >_______________________________________________ > > >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 br@brianrosen.net Mon Jul 23 06: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 7CC0121F8627 for ; Mon, 23 Jul 2012 06:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=-1.312, BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1, 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 ld5xVEjTqQJ6 for ; Mon, 23 Jul 2012 06:48:12 -0700 (PDT) Received: from barmail6.idig.net (barmail6.idig.net [64.34.111.239]) by ietfa.amsl.com (Postfix) with ESMTP id 5724121F85F9 for ; Mon, 23 Jul 2012 06:48:12 -0700 (PDT) X-ASG-Debug-ID: 1343051290-0538de37f670b980001-sFFYAS Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail6.idig.net with ESMTP id fyVDpayVbEuONtY1; Mon, 23 Jul 2012 06:48:10 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233]:21533 helo=[192.168.133.1]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1StIzY-002YyF-R4; Mon, 23 Jul 2012 06:48:09 -0700 References: <20120703060324.32593.96953.idtracker@ietfa.amsl.com> <9F33F40F6F2CD847824537F3C4E37DDF043651@MCHP04MSX.global-ad.net> <05D56509F27CCE4DAF8136C02386880D68647287@exc01.dss.lan> <9F33F40F6F2CD847824537F3C4E37DDF056C78@MCHP04MSX.global-ad.net> <05D56509F27CCE4DAF8136C02386880D686ADD1C@exc01.dss.lan> In-Reply-To: <05D56509F27CCE4DAF8136C02386880D686ADD1C@exc01.dss.lan> Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 Message-Id: <489E5C88-9B66-499D-9268-0CB32244A1E2@brianrosen.net> Content-Transfer-Encoding: quoted-printable From: Brian Rosen Date: Mon, 23 Jul 2012 09:48:01 -0400 X-ASG-Orig-Subj: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-07.txt To: Michael Smith X-Mailer: Apple Mail (2.1278) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1343051290 X-Barracuda-URL: http://64.34.111.239: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.103529 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 Cc: "siprec@ietf.org" Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-07.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, 23 Jul 2012 13:48:13 -0000 There are two ways to participate remotely. One is the RTSP streaming service. If you go to the tools meeting = agenda: http://tools.ietf.org/agenda/84/ you will find the link for the stream. This is play only. You then also join the jabber room, the link is on the same page. To = ask a question (or make an observation) you type "mic:" and your = question/comment. The designated jabber scribe will go to the floor = microphone on your behalf. The RSTP stream runs many seconds behind. The other way is meetecho. They will be supporting the siprec session. = You should be able to find the link on: http://ietf84.conf.meetecho.com/ This is a real time multimedia streaming service with audio, video and = text. This is all detailed at: http://www.ietf.org/meeting/84/remote-participation.html Brian On Jul 23, 2012, at 9:34 AM, Michael Smith wrote: > Andy, >=20 > I can't make the IETF meeting. I didn't know it was possible to join = remotely, but I'd like to. Is the info for joining remotely on the = IETF84 pages? >=20 > Michael Smith > Chief Technologist > Ph: 606.877.2788 | Mobile: 606.231.0243=20 >=20 > DSS Corporation / Equature > 18311 W. Ten Mile Road, Suite 200 > Southfield, MI - 48075 > Tel: 1-888.305.3428 > Fax: 1-248.569.6567 > www.dss-corp.com > www.dispatchimprovement.com >=20 >=20 > -----Original Message----- > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com]=20 > Sent: Tuesday, July 17, 2012 8:45 AM > To: Michael Smith; siprec@ietf.org > Subject: RE: [siprec] I-D Action: draft-ietf-siprec-metadata-07.txt >=20 > Hi Michael, >=20 > Thanks for volunteering to review this draft and sorry it took so long = for me to respond. >=20 > Yes the link you indicated below will point you at the right version. >=20 > It is great to know that NENA are interested in our work. >=20 > Any chance you will be in Vancouver for IETF84 or if not maybe you can = join the session remotely? >=20 > Also it would be great to have your comments anytime but if you could = make it before the IETF84 meeting then we could discuss any issues = raised there. >=20 > Regards > Andy (SIPREC Co-Chair). >=20 >=20 >=20 >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >> Behalf Of Michael Smith >> Sent: 09 July 2012 15:15 >> To: siprec@ietf.org >> Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-07.txt >>=20 >> Andy, >>=20 >> I volunteer to do a review; is this the correct version: >> https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/ ? >>=20 >> Note: I'll limit my comments to basic editorial stuff, and things I'm=20= >> pretty sure are real issues, since I've only recently become familiar=20= >> with SIPREC and don't want to waste your time on things I simply = don't=20 >> understand. BTW, Brian Rosen knows me from NENA work. I'm on his LTD=20= >> working group, and lead the NG9-1-1 PSAP working group, and the=20 >> recording test committee. We've proposed using SIPREC as the media=20 >> recording protocol in NG9-1-1. >>=20 >> Reviewing this draft will help me understand better, and hopefully=20 >> provide some usable feedback to you. >>=20 >> Regards, >>=20 >> Michael Smith >> Chief Technologist >> Ph: 606.877.2788 | Mobile: 606.231.0243 >>=20 >> DSS Corporation / Equature >> 18311 W. Ten Mile Road, Suite 200 >> Southfield, MI - 48075 >> Tel: 1-888.305.3428 >> Fax: 1-248.569.6567 >> www.dss-corp.com >> www.dispatchimprovement.com >>=20 >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >> Behalf Of Hutton, Andrew >> Sent: Monday, July 09, 2012 9:46 AM >> To: siprec@ietf.org >> Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-07.txt >>=20 >> Hi All, >>=20 >> We need a few volunteers to do a full review of the SIPREC metadata=20= >> draft. >>=20 >> If you are able to volunteer for this please let me know. >>=20 >> If we could have some people review the draft before IETF84 then that=20= >> would be perfect. >>=20 >> Regards >> Andy (SIPREC Co-Chair). >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>> Behalf Of Ram Mohan R (rmohanr) >>> Sent: 03 July 2012 07:17 >>> To: internet-drafts@ietf.org; i-d-announce@ietf.org >>> Cc: siprec@ietf.org >>> Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-07.txt >>>=20 >>> Hi all, >>>=20 >>> This version of the draft tries the incorporate the comments=20 >>> received in IETF 83 Refer to >>> http://www.ietf.org/proceedings/83/minutes/minutes-83- >>> siprec.pdf >>> for the minutes. >>>=20 >>> To summarize it has following changes: >>> 1) Incorporated start/stop times for CS >>> 2) Edits to CSRS association and ParticipantCSAssociation >>> 3) Minor NITS received as comments in previous version >>> 4) Modified the XML to have id as just id instead of group_id e.t.c=20= >>> and session instead of session_id. >>> 5) Modified the examples to reflect the change in schema in [4] >>>=20 >>> Please review the draft and provide your comments. >>>=20 >>> Authors >>>=20 >>> On 03/07/12 11:33 AM, "internet-drafts@ietf.org" >>> wrote: >>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts=20= >>>> directories. >>>> This draft is a work item of the SIP Recording Working Group of=20 >>>> the >>> IETF. >>>>=20 >>>> Title : Session Initiation Protocol (SIP) Recording >>> Metadata >>>> Author(s) : Ram Mohan Ravindranath >>>> Parthasarathi Ravindran >>>> Paul Kyzivat >>>> Filename : draft-ietf-siprec-metadata-07.txt >>>> Pages : 48 >>>> Date : 2012-07-02 >>>>=20 >>>> Abstract: >>>> Session recording is a critical requirement in many >> communications >>>> environments such as call centers and financial trading. In=20 >>>> 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. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-siprec-metadata-07 >>>>=20 >>>> A diff from previous version is available at: >>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-metadata-07 >>>>=20 >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>>>=20 >>>=20 >>>=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 prvs=15514aa549=MSmith@dss-corp.com Mon Jul 23 06:49: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 090B111E808A for ; Mon, 23 Jul 2012 06:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 eEEWF+y+8MfG for ; Mon, 23 Jul 2012 06:49:27 -0700 (PDT) Received: from spam.dss-corp.com (spam.dss-corp.com [67.214.118.46]) by ietfa.amsl.com (Postfix) with ESMTP id F128321F868A for ; Mon, 23 Jul 2012 06:49:26 -0700 (PDT) Received: from spam.dss-corp.com (127.0.0.1) by spam.dss-corp.com (MlfMTA v3.2r9) id h1lc0o0171sa for ; Mon, 23 Jul 2012 09:56:28 -0400 (envelope-from ) Received: from exc.dss-corp.com ([192.168.1.5]) by spam.dss-corp.com (SonicWALL 7.2.4.3929) with ESMTP; Mon, 23 Jul 2012 09:56:27 -0400 Received: from EXC01.dss.lan ([fe80::109b:ad4:1a47:2813]) by exc01.dss.lan ([fe80::109b:ad4:1a47:2813%13]) with mapi; Mon, 23 Jul 2012 09:49:28 -0400 From: Michael Smith To: Brian Rosen Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-metadata-07.txt Thread-Index: AQHNWOGZ1iutGtCPoUO5Vodq+FzB9JcXWDqAgAnrRgD//8LLgIAMvumAgAk4mZCAAEcKgP//vT4g Date: Mon, 23 Jul 2012 13:49:21 +0000 Message-ID: <05D56509F27CCE4DAF8136C02386880D686ADDAA@exc01.dss.lan> References: <20120703060324.32593.96953.idtracker@ietfa.amsl.com> <9F33F40F6F2CD847824537F3C4E37DDF043651@MCHP04MSX.global-ad.net> <05D56509F27CCE4DAF8136C02386880D68647287@exc01.dss.lan> <9F33F40F6F2CD847824537F3C4E37DDF056C78@MCHP04MSX.global-ad.net> <05D56509F27CCE4DAF8136C02386880D686ADD1C@exc01.dss.lan> <489E5C88-9B66-499D-9268-0CB32244A1E2@brianrosen.net> In-Reply-To: <489E5C88-9B66-499D-9268-0CB32244A1E2@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mlf-Version: 7.2.4.3929 X-Mlf-UniqueId: o201207231356270069317 Cc: "siprec@ietf.org" Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-07.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, 23 Jul 2012 13:49:28 -0000 Thanks, Brian - I'll do it! Michael Smith Chief Technologist Ph: 606.877.2788 | Mobile: 606.231.0243=20 DSS Corporation / Equature 18311=A0=A0 W. Ten Mile Road, Suite 200 Southfield, MI - 48075 Tel: 1-888.305.3428 Fax: 1-248.569.6567 www.dss-corp.com www.dispatchimprovement.com -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Monday, July 23, 2012 9:48 AM To: Michael Smith Cc: Hutton, Andrew; siprec@ietf.org Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-07.txt There are two ways to participate remotely. One is the RTSP streaming service. If you go to the tools meeting agenda: http://tools.ietf.org/agenda/84/ you will find the link for the stream. This is play only. You then also join the jabber room, the link is on the same page. To ask a= question (or make an observation) you type "mic:" and your question/commen= t. The designated jabber scribe will go to the floor microphone on your be= half. The RSTP stream runs many seconds behind. The other way is meetecho. They will be supporting the siprec session. Yo= u should be able to find the link on: http://ietf84.conf.meetecho.com/ This is a real time multimedia streaming service with audio, video and text= . This is all detailed at: http://www.ietf.org/meeting/84/remote-participation.html Brian On Jul 23, 2012, at 9:34 AM, Michael Smith wrote: > Andy, >=20 > I can't make the IETF meeting. I didn't know it was possible to join remo= tely, but I'd like to. Is the info for joining remotely on the IETF84 pages= ? >=20 > Michael Smith > Chief Technologist > Ph: 606.877.2788 | Mobile: 606.231.0243 >=20 > DSS Corporation / Equature > 18311 W. Ten Mile Road, Suite 200 > Southfield, MI - 48075 > Tel: 1-888.305.3428 > Fax: 1-248.569.6567 > www.dss-corp.com > www.dispatchimprovement.com >=20 >=20 > -----Original Message----- > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > Sent: Tuesday, July 17, 2012 8:45 AM > To: Michael Smith; siprec@ietf.org > Subject: RE: [siprec] I-D Action: draft-ietf-siprec-metadata-07.txt >=20 > Hi Michael, >=20 > Thanks for volunteering to review this draft and sorry it took so long fo= r me to respond. >=20 > Yes the link you indicated below will point you at the right version. >=20 > It is great to know that NENA are interested in our work. >=20 > Any chance you will be in Vancouver for IETF84 or if not maybe you can jo= in the session remotely? >=20 > Also it would be great to have your comments anytime but if you could mak= e it before the IETF84 meeting then we could discuss any issues raised ther= e. >=20 > Regards > Andy (SIPREC Co-Chair). >=20 >=20 >=20 >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >> Behalf Of Michael Smith >> Sent: 09 July 2012 15:15 >> To: siprec@ietf.org >> Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-07.txt >>=20 >> Andy, >>=20 >> I volunteer to do a review; is this the correct version: >> https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/ ? >>=20 >> Note: I'll limit my comments to basic editorial stuff, and things I'm=20 >> pretty sure are real issues, since I've only recently become familiar=20 >> with SIPREC and don't want to waste your time on things I simply=20 >> don't understand. BTW, Brian Rosen knows me from NENA work. I'm on=20 >> his LTD working group, and lead the NG9-1-1 PSAP working group, and=20 >> the recording test committee. We've proposed using SIPREC as the=20 >> media recording protocol in NG9-1-1. >>=20 >> Reviewing this draft will help me understand better, and hopefully=20 >> provide some usable feedback to you. >>=20 >> Regards, >>=20 >> Michael Smith >> Chief Technologist >> Ph: 606.877.2788 | Mobile: 606.231.0243 >>=20 >> DSS Corporation / Equature >> 18311 W. Ten Mile Road, Suite 200 >> Southfield, MI - 48075 >> Tel: 1-888.305.3428 >> Fax: 1-248.569.6567 >> www.dss-corp.com >> www.dispatchimprovement.com >>=20 >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >> Behalf Of Hutton, Andrew >> Sent: Monday, July 09, 2012 9:46 AM >> To: siprec@ietf.org >> Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-07.txt >>=20 >> Hi All, >>=20 >> We need a few volunteers to do a full review of the SIPREC metadata=20 >> draft. >>=20 >> If you are able to volunteer for this please let me know. >>=20 >> If we could have some people review the draft before IETF84 then that=20 >> would be perfect. >>=20 >> Regards >> Andy (SIPREC Co-Chair). >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>> Behalf Of Ram Mohan R (rmohanr) >>> Sent: 03 July 2012 07:17 >>> To: internet-drafts@ietf.org; i-d-announce@ietf.org >>> Cc: siprec@ietf.org >>> Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-07.txt >>>=20 >>> Hi all, >>>=20 >>> This version of the draft tries the incorporate the comments=20 >>> received in IETF 83 Refer to >>> http://www.ietf.org/proceedings/83/minutes/minutes-83- >>> siprec.pdf >>> for the minutes. >>>=20 >>> To summarize it has following changes: >>> 1) Incorporated start/stop times for CS >>> 2) Edits to CSRS association and ParticipantCSAssociation >>> 3) Minor NITS received as comments in previous version >>> 4) Modified the XML to have id as just id instead of group_id e.t.c=20 >>> and session instead of session_id. >>> 5) Modified the examples to reflect the change in schema in [4] >>>=20 >>> Please review the draft and provide your comments. >>>=20 >>> Authors >>>=20 >>> On 03/07/12 11:33 AM, "internet-drafts@ietf.org" >>> wrote: >>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>>> directories. >>>> This draft is a work item of the SIP Recording Working Group of the >>> IETF. >>>>=20 >>>> Title : Session Initiation Protocol (SIP) Recording >>> Metadata >>>> Author(s) : Ram Mohan Ravindranath >>>> Parthasarathi Ravindran >>>> Paul Kyzivat >>>> Filename : draft-ietf-siprec-metadata-07.txt >>>> Pages : 48 >>>> Date : 2012-07-02 >>>>=20 >>>> Abstract: >>>> Session recording is a critical requirement in many >> communications >>>> environments such as call centers and financial trading. In=20 >>>> 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. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-siprec-metadata-07 >>>>=20 >>>> A diff from previous version is available at: >>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-metadata-07 >>>>=20 >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>>>=20 >>>=20 >>>=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 rmohanr@cisco.com Tue Jul 24 00:57: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 A097A21F8649 for ; Tue, 24 Jul 2012 00:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 v9Di79CtF9zY for ; Tue, 24 Jul 2012 00:57:19 -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 9C78921F8647 for ; Tue, 24 Jul 2012 00:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=652; q=dns/txt; s=iport; t=1343116639; x=1344326239; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=C1zsxz0hTcuotfdZWQ7L3Y/T7XleNzT52hoHIFF01+g=; b=a76+X4sCpjZGp8zj1G4dfH79GTkt7Qaj9z6SQyn5pZ1roXlhArmpoK80 PoPO8VDJCLGDusixFisRZikqFC40+L/IWtB90pvOPddeTmAdv5eAQ7Kt6 EXc7aQSQHmwerlVZq4dZHI4zMf+GIdNsVuDzP+bCXjojtZKNVIBIkp3RT Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAH1UDlCtJV2Y/2dsb2JhbABFhSy0P4EHgiABAQEDARIBJz8FDQEINkIlAgQOBSKHZQacQ6A+kj4DlUmOJ4Fmgl8 X-IronPort-AV: E=Sophos;i="4.77,644,1336348800"; d="scan'208";a="104685051" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 24 Jul 2012 07:57:19 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6O7vJj5014375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Jul 2012 07:57:19 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.114]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0298.004; Tue, 24 Jul 2012 02:57:18 -0500 From: "Ram Mohan R (rmohanr)" To: "Ravindran, Parthasarathi" Thread-Topic: Editorial review comment in Metadata draft Thread-Index: AQHNaXHypPOh+5l3XUWqtVirTWNWJQ== Date: Tue, 24 Jul 2012 07:57:17 +0000 Message-ID: In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C2BA271EF@inba-mail02.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [173.39.68.80] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19060.004 x-tm-as-result: No--27.562800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <7819CC31649F9945B1B1FB8CC47B74DA@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Editorial review comment in Metadata draft 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, 24 Jul 2012 07:57:23 -0000 Thanks for noting these. I will make a note and update in the next revision. Ram > On 23/07/12 8:40 AM, "Ravindran, Parthasarathi" > wrote: >Hi Ram, > >I noticed that the following editorial review comments in the (-07) of >metadata draft > >1) CSRSAssociation metadata block is not added in the metadata model >whereas it is explained in Sec 6.4 > >2) Removal of csrc element in stream to make the schema inline with >stream metadata attributes minOccurs=3D'0' maxOccurs=3D'1' > >Please consider these updates in the next revision. > >Thanks >Partha > From simon.farrow@stancilcorp.com Tue Jul 24 07:37: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 B4A8421F8661 for ; Tue, 24 Jul 2012 07:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 hoZN8qi0VQt8 for ; Tue, 24 Jul 2012 07:37:37 -0700 (PDT) Received: from mail44.atl.registeredsite.com (mail44.atl.registeredsite.com [209.237.134.234]) by ietfa.amsl.com (Postfix) with ESMTP id D152921F8655 for ; Tue, 24 Jul 2012 07:37:36 -0700 (PDT) Received: from mymail.myregisteredsite.com (wmailnode1c.webmail.web.com [209.237.134.168]) by mail44.atl.registeredsite.com (8.12.11.20060308/8.12.11) with SMTP id q6OEbYti025746 for ; Tue, 24 Jul 2012 10:37:35 -0400 Received: (qmail 9710 invoked by uid 80); 24 Jul 2012 14:37:34 -0000 Received: from unknown (HELO VOXSTORSERVER) (simon.farrow@stancilcorp.com@65.244.196.81) by wmailnode1c.mymail.myregisteredsite.com with ESMTPA; 24 Jul 2012 14:37:34 -0000 From: "Simon Farrow" To: "'Ram Mohan R \(rmohanr\)'" , "'Hutton, Andrew'" References: <387F9047F55E8C42850AD6B3A7A03C6C2BA271EF@inba-mail02.sonusnet.com> Date: Tue, 24 Jul 2012 07:36:03 -0700 Organization: Stancil Corporation Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01CD696E.FD223950" X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac1ogNxoAWfXFhqhSY25AEIrz8T/mABJzOpg In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C2BA271EF@inba-mail02.sonusnet.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: siprec@ietf.org Subject: [siprec] Editorial review comment in Metadata draft X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: simon.farrow@stancilcorp.com List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 14:37:38 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0012_01CD696E.FD223950 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ram / Andy I have the following observations upon reviewing the pdf version 7 metadata draft dated 3rd July 2012. I appreciate these comments are editoral but hopefully they will helpful for the clarify of the document. 6.4.1. Attributes CSRS association class has the following attributes: Associate-time - associate-time is calculated by SRC as the time it sees a CS is associated to a RS Missing 'a' before RS. Page 38 Missing '_id' Page 39 Missing '_id' and stream id should be stream_id 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== UAAMm5GRQKSCMVvLyl4rFw== i1Pz3to5hGk8fuXl+PbwCw== Page 40 Missing '_id' partial 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== Page 46 Missing 's' on the first disassociate-time 2010-12-16T23:41:07Z associate-time The latter examples in Appendix B are continuation of earlier examples. The associate-time is the same for all examples. For clarity should the latter examples be later or am I missing something. Simon Farrow Stancil Corporation 2644 South Croddy Way Santa Ana CA 92704 http://www.stancilcorp.com simon.farrow@stancilcorp.com 714-546-2002 ext 4311 ------=_NextPart_000_0012_01CD696E.FD223950 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ram / Andy

I have the following = observations=20 upon reviewing the pdf version 7 metadata draft dated 3rd July 2012. I=20 appreciate these comments are editoral but hopefully they will helpful = for the=20 clarify of the document.

6.4.1.  = Attributes

   = CSRS=20 association class has the following attributes:

   = Associate-time=20 - associate-time is calculated by SRC as the time it sees a CS is = associated to=20 a=20 RS

Missing ‘a’ before RS.

Page=20 38

Missing  = ‘_id’

<participantsessionassoc

           &n= bsp; =20 participant_id = =3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"

           &n= bsp; =20 session_id=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">

 

Page=20 39

 

Missing  = ‘_id’ and stream id=20 should be stream_id

<participantstreamassoc

           &n= bsp; =20 participant_id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D">

           =20 <send>8zc6e0lYTlWIINA6GR+3ag=3D=3D</send>

           =20 <send>EiXGlc+4TruqqoDaNE76ag=3D=3D</send>

           =20 <recv>UAAMm5GRQKSCMVvLyl4rFw=3D=3D</recv>

           =20 <recv>i1Pz3to5hGk8fuXl+PbwCw=3D=3D</recv>

         =20 </participantstreamassoc>

         =20 <stream_id=3D"UAAMm5GRQKSCMVvLyl4rFw=3D=3D"

           &n= bsp; =20 session_id=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">

           &n= bsp; =20 <label>96</label>

         =20 </stream>

         =20 <stream_id=3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"

             &n= bsp;session_id=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">

           &n= bsp; =20 <label>97</label>

         =20 </stream>

         =20 <stream_id=3D"8zc6e0lYTlWIINA6GR+3ag=3D=3D"

session_id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D">

           &n= bsp; =20 <label>98</label>

         =20 </stream>

         =20 <stream_id=3D"EiXGlc+4TruqqoDaNE76ag=3D=3D"

           &n= bsp; =20 session_id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D">

           &n= bsp; =20 <label>99</label>

         =20 </stream>

 

 

Page=20 40

Missing  = ‘_id’

 

<?xml version=3D"1.0" encoding=3D"UTF-8"?>

       =20 <recording=20 xmlns=3D’urn:ietf:params:xml:ns:recording’><= /P>

         =20 <dataMode>partial</dataMode>

           =20 <participantstreamassoc

           &n= bsp;=20 participant_id = =3D"srfBElmCRp2QB23b7Mpk0w=3D=3D"

           &n= bsp;=20 session_id=20 =3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">

           &n= bsp;=20 <recv>8zc6e0lYTlWIINA6GR+3ag=3D=3D</recv>

           =20  <recv>EiXGlc+4TruqqoDaNE76ag=3D=3D</recv>

           =20 </participantstreamassoc>

           =20 <participantstreamassoc

           &n= bsp;=20 participant_id = =3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"

           &n= bsp;=20 session_id=20 =3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">

 

Page=20 46

Missing=20 ‘s’ on the first disassociate-time

<disassociate-time>2010-12-16T23:41:07Z</dis= associate-time>

 

associate-time

The=20 latter examples in Appendix B are continuation of earlier examples. The=20 associate-time is the same for all examples. For clarity should the = latter=20 examples be later or am I missing something.

 

Simon Farrow
Stancil Corporation
2644 South = Croddy=20 Way
Santa Ana
CA 92704
http://www.stancilcorp.com
simon.farrow@stancilcorp.com
714-546-2002 ext=20 4311

------=_NextPart_000_0012_01CD696E.FD223950-- From rmohanr@cisco.com Tue Jul 24 10:05: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 EF3CA21F84F4 for ; Tue, 24 Jul 2012 10:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 RDNAgNFg1jRV for ; Tue, 24 Jul 2012 10:05:12 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id ECC9921F84F3 for ; Tue, 24 Jul 2012 10:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=3909; q=dns/txt; s=iport; t=1343149512; x=1344359112; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=JBtvYBADVg1jgdlIfsDZIvdDMkvXFJFhjJPXWuHMYts=; b=OOkw88RpB5rgoJ4P6Ca7sg9WOljlPF9hxvTtOe8HYeY3FHPG2BKODHXb e+n9zF8wiCMqITkVupYx3jwAaMhaam3Rx39fAzKO40yKk1ybxc7nCX8jn hAR7ShEj+IqtOFOB8FtdTvZPsDtVX79ZwQBieGgV0pT6m0raY+BMFB9mj 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAEXVDlCtJXG+/2dsb2JhbABCA7l5gQeCIAEBAQMBDAYBQiQFDQEIeCUCBA4FIodlBpsgoEWLS4NTgyEDlUmOJ4Fmgl8 X-IronPort-AV: E=Sophos;i="4.77,647,1336348800"; d="scan'208";a="104644364" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 24 Jul 2012 17:05:11 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6OH5Bcf027636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Jul 2012 17:05:11 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.114]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Tue, 24 Jul 2012 12:03:33 -0500 From: "Ram Mohan R (rmohanr)" To: "simon.farrow@stancilcorp.com" , "'Hutton, Andrew'" Thread-Topic: [siprec] Editorial review comment in Metadata draft Thread-Index: AQHNab57pelBhwKgmkuH3VQtjqKKdQ== Date: Tue, 24 Jul 2012 17:05:10 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.65.80.195] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19060.006 x-tm-as-result: No--44.086100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Editorial review comment in Metadata draft 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, 24 Jul 2012 17:05:13 -0000 Hi Simon, > On 24/07/12 8:06 PM, "Simon Farrow" wrote: >Ram / Andy > >I have the following observations >upon reviewing the pdf version 7 metadata draft dated 3rd July 2012. I >appreciate these comments are editoral but hopefully they will helpful >for the=20 >clarify of the document. Sure. Any comments are appreciated as it helps in making document better. Thanks for taking time to review the document. Please see inline for answers. > > >6.4.1. Attributes > CSRS=20 >association class has the following attributes: > Associate-time=20 >- associate-time is calculated by SRC as the time it sees a CS is >associated to=20 >a=20 >RS >Missing =8Ca=B9 before RS. Will change this in the next revision. >Page=20 >38 >Missing =8C_id=B9 > =20 >participant_id =3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D" > =20 >session_id=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> >=20 >Page=20 >39 >=20 >Missing =8C_id=B9 and stream id >should be stream_id > =20 >participant_id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> > =20 >8zc6e0lYTlWIINA6GR+3ag=3D=3D > =20 >EiXGlc+4TruqqoDaNE76ag=3D=3D > =20 >UAAMm5GRQKSCMVvLyl4rFw=3D=3D > =20 >i1Pz3to5hGk8fuXl+PbwCw=3D=3D > =20 > > =20 > =20 >session_id=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > =20 > > =20 > > =20 > session_id=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > =20 > > =20 > > =20 >session_id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> > =20 > > =20 > > =20 > =20 >session_id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> > =20 > > =20 > >=20 >=20 >Page=20 >40 >Missing =8C_id=B9 >=20 > > =20 >xmlns=3D=B9urn:ietf:params:xml:ns:recording=B9> > =20 >partial > =20 > =20 >participant_id =3D"srfBElmCRp2QB23b7Mpk0w=3D=3D" > =20 >session_id=20 >=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > =20 >8zc6e0lYTlWIINA6GR+3ag=3D=3D > =20 > EiXGlc+4TruqqoDaNE76ag=3D=3D > =20 > > =20 > =20 >participant_id =3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D" > =20 >session_id=20 >=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> Yes. We will update the examples to be in consistent with schema and have _id for all the element ids as you mentioned in page 38,39 and 40 and elsewhere in the document. >=20 >Page=20 >46 >Missing=20 >=8Cs=B9 on the first disassociate-time >2010-12-16T23:41:07Z Thanks for pointing out. I will fix in next revision. >=20 >associate-time >The=20 >latter examples in Appendix B are continuation of earlier examples. The >associate-time is the same for all examples. For clarity should the >latter=20 >examples be later or am I missing something. Yes. This needs to be changed. We have a separate document for call flows now. We will fix the associate-time in the examples in both docs. Thanks, Ram >=20 >Simon Farrow >Stancil Corporation >2644 South Croddy=20 >Way >Santa Ana >CA 92704 >http://www.stancilcorp.com >simon.farrow@stancilcorp.com >714-546-2002 ext=20 >4311 > > > From Henry.Lum@genesyslab.com Thu Jul 26 08:51: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 D088F21F8596 for ; Thu, 26 Jul 2012 08:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.396 X-Spam-Level: X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=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 t-Sbxd0arKSx for ; Thu, 26 Jul 2012 08:51:28 -0700 (PDT) Received: from relay-out2.dc.genesyslab.com (relay-out2.dc.genesyslab.com [198.49.180.221]) by ietfa.amsl.com (Postfix) with ESMTP id F069121F858F for ; Thu, 26 Jul 2012 08:51:27 -0700 (PDT) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id q6QFpQgU029298; Thu, 26 Jul 2012 08:51:26 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Jul 2012 08:51:26 -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, 26 Jul 2012 08:51:23 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF7408D047C2@NAHALD.us.int.genesyslab.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828042AD2@xmb-aln-x08.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] comments on draft-ietf-siprec-protocol-06 Thread-Index: Ac1l/+S2usiuTbtLTba/unvcA+nRVQFQbyQw References: <92B7E61ADAC1BB4F941F943788C08828042AD2@xmb-aln-x08.cisco.com> From: "Henry Lum" To: "Charles Eckel (eckelcu)" , X-OriginalArrivalTime: 26 Jul 2012 15:51:26.0115 (UTC) FILETIME=[83779F30:01CD6B46] Subject: Re: [siprec] comments on draft-ietf-siprec-protocol-06 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, 26 Jul 2012 15:51:29 -0000 Hi Charles, Please see inline. Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of > Charles Eckel (eckelcu) > Sent: July-19-12 6:43 PM > To: siprec@ietf.org > Subject: [siprec] comments on draft-ietf-siprec-protocol-06 >=20 > I have one major comment and one minor comment on the draft. I'll start with > the major comment. >=20 > Section 6.1 and section 6.2 discuss the use for the +sip.src/+sip.srs feature > tag and siprec option tag by a SRC/SRS to start an RS. The section clearly and > correctly states that both the feature tag and the option tag must be present. > However, the sections also describe the usage of the +sip.src/+sip.srs feature > tags in REGISTSER messages. The usage of +sip.src/+sip.srs feature tag without > the siprec options tag in other requests, such as INVITE, is not covered. The > meaning of these feature tags to UAs in not addressed. [Henry] The intention to require both option tag and feature tag is to first identify that a session is a recording session with the option tag, and then identify the party (SRC/SRS) with the feature tag. Without the option tag, a session should not be considered a recording session; how the UA treats a party in a normal SIP session with a src/srs feature tag should be up to the UA. For example, the SRC may tell the participant that it is an SRC and the participant may choose to do nothing with this or include the recording preference to indicate the wish to record. You are right that it is not quite clear what this means and it's not covered in both section 6 and 11. > I suggest to change section 6 from "Initiating a Recording" to "SIP > Handling". This is more in line with the approach take in sections 7 and 8, > which are titled "SDP Handling" and "RTP Handling". Within section 6 was can > have: > 6.1 Procedures at the SRC > 6.2 Procedures at the SRS > 6.3 Procedures at Recording-aware UAs >=20 > To the existing section 7, we can add: > Section 7.3 Procedures at Recording-Aware UAs. > The material currently in section 11 gets relocated into section 6 and 7 > accordingly. [Henry] The original thought is to organize recording indication and preference as a separate section to explain how this is used between record-aware UA and SRC, and not mix this with the recording session. Now that the introductory text on how recording preference is used is moved to section 5.3, it is possible re-align the major headings as SIP, SDP, RTP/RTCP handling, Metadata. Let's see what others think about reorganization. > In addition to simply reorganizing, we also clarify what it means for a UA to > receive to INVITE or 200 OK from an SRC that includes +sip.src. I take this to > mean that the thing the UA is talking to is able to act as a SIPREC SRC, even > though it may not be recording currently. This may be useful in some > scenarios, such as for an MCU to know that one of the participants in the > conference is a recorder. Consequently the UA or MCU may want to indicate a > recording preference, and/or pay attention to any SDP record attributes. [Henry] As long as the MCU indicates recording-aware support in the initial INVITE request/response, then the MCU should be able to find out which participant is an SRC and provide the recording preference later in the call. This needs to be clarified as you suggested in the first comment. =20 > Whether or not the UA/MCU can influence the operation of the SRC remains a > policy decision of the SRC, as currently described in the draft. >=20 > My minor/editorial comment is in regard to section 5.3. This section provides > good introductory information; however, the first paragraph does not read well > in my opinion. I think it would benefit from separating the record and > recordpref attributes discussion a bit. Proposed text is as follows: >=20 [Henry] Thanks, this reads much better. > "The SRC is responsible for providing recording indications to the > participants in the CS. The SRC does so using the SIPREC defined SDP attribute > a=3Drecord. This attribute is used as a declaration by the SRC to indicate > whether recording of the CS is taking place . The SRC may use other recording > indication mechanisms as well; however, such mechanisms are outside the scope > of SIPREC. > Recording-aware UAs can indicate a recording preference in the CS using the > SIPREC defined SDP attribute a=3Drecordpref. The recording preference attribute > is a declaration by the recording-aware UA of its recording preference. The > SRC is not obligated to honor a recording preference provided by a UA, as it > is merely an indication of a preference, not a direct command or request to > start or stop recording." >=20 > Cheers, > Charles > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Thu Jul 26 09:39: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 9F44D21F863C for ; Thu, 26 Jul 2012 09:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=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 Qm+a15kB6hxF for ; Thu, 26 Jul 2012 09:39:52 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id BA2AA21F8643 for ; Thu, 26 Jul 2012 09:39:51 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta09.westchester.pa.mail.comcast.net with comcast id ezPm1j0010bG4ec594fqJ9; Thu, 26 Jul 2012 16:39:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id f4fn1j00e3ZTu2S3P4fnBh; Thu, 26 Jul 2012 16:39:47 +0000 Message-ID: <501172D2.4010201@alum.mit.edu> Date: Thu, 26 Jul 2012 12:39:46 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <92B7E61ADAC1BB4F941F943788C08828042AD2@xmb-aln-x08.cisco.com> <059AF07365DC474393A19A3AF187DF7408D047C2@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF7408D047C2@NAHALD.us.int.genesyslab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] comments on draft-ietf-siprec-protocol-06 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, 26 Jul 2012 16:39:52 -0000 On 7/26/12 11:51 AM, Henry Lum wrote: > Hi Charles, > > Please see inline. > > Henry > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of >> Charles Eckel (eckelcu) >> Sent: July-19-12 6:43 PM >> To: siprec@ietf.org >> Subject: [siprec] comments on draft-ietf-siprec-protocol-06 >> >> I have one major comment and one minor comment on the draft. I'll > start with >> the major comment. >> >> Section 6.1 and section 6.2 discuss the use for the +sip.src/+sip.srs > feature >> tag and siprec option tag by a SRC/SRS to start an RS. The section > clearly and >> correctly states that both the feature tag and the option tag must be > present. >> However, the sections also describe the usage of the +sip.src/+sip.srs > feature >> tags in REGISTSER messages. The usage of +sip.src/+sip.srs feature tag > without >> the siprec options tag in other requests, such as INVITE, is not > covered. The >> meaning of these feature tags to UAs in not addressed. > > [Henry] The intention to require both option tag and feature tag is to > first identify that a session is a recording session with the option > tag, and then identify the party (SRC/SRS) with the feature tag. Without > the option tag, a session should not be considered a recording session; > how the UA treats a party in a normal SIP session with a src/srs feature > tag should be up to the UA. For example, the SRC may tell the > participant that it is an SRC and the participant may choose to do > nothing with this or include the recording preference to indicate the > wish to record. You are right that it is not quite clear what this means > and it's not covered in both section 6 and 11. I take slight issue with the above. The option tag cannot indicate that the session *is* a recording session. All an option tag can do is indicate *support* for features. So for instance I *could* send you an INVITE with Require:siprec and yet have it be a regular call. But it would fail unless you are *capable* of a recording session. The definitive signaling that this *is* an RS should be the metadata. I (reluctantly) have agreed that we can get away with interpreting the presence of the +sip.src or +sip.srs tag as meaning that end intends to act in that role, rather than simply being *capable* of doing so. We have some precedent for such usage, such as with isFocus. Thanks, Paul >> I suggest to change section 6 from "Initiating a Recording" to "SIP >> Handling". This is more in line with the approach take in sections 7 > and 8, >> which are titled "SDP Handling" and "RTP Handling". Within section 6 > was can >> have: >> 6.1 Procedures at the SRC >> 6.2 Procedures at the SRS >> 6.3 Procedures at Recording-aware UAs >> >> To the existing section 7, we can add: >> Section 7.3 Procedures at Recording-Aware UAs. >> The material currently in section 11 gets relocated into section 6 and > 7 >> accordingly. > > [Henry] The original thought is to organize recording indication and > preference as a separate section to explain how this is used between > record-aware UA and SRC, and not mix this with the recording session. > Now that the introductory text on how recording preference is used is > moved to section 5.3, it is possible re-align the major headings as SIP, > SDP, RTP/RTCP handling, Metadata. Let's see what others think about > reorganization. > >> In addition to simply reorganizing, we also clarify what it means for > a UA to >> receive to INVITE or 200 OK from an SRC that includes +sip.src. I take > this to >> mean that the thing the UA is talking to is able to act as a SIPREC > SRC, even >> though it may not be recording currently. This may be useful in some >> scenarios, such as for an MCU to know that one of the participants in > the >> conference is a recorder. Consequently the UA or MCU may want to > indicate a >> recording preference, and/or pay attention to any SDP record > attributes. > > [Henry] As long as the MCU indicates recording-aware support in the > initial INVITE request/response, then the MCU should be able to find out > which participant is an SRC and provide the recording preference later > in the call. This needs to be clarified as you suggested in the first > comment. > >> Whether or not the UA/MCU can influence the operation of the SRC > remains a >> policy decision of the SRC, as currently described in the draft. >> >> My minor/editorial comment is in regard to section 5.3. This section > provides >> good introductory information; however, the first paragraph does not > read well >> in my opinion. I think it would benefit from separating the record and >> recordpref attributes discussion a bit. Proposed text is as follows: >> > [Henry] Thanks, this reads much better. > > >> "The SRC is responsible for providing recording indications to the >> participants in the CS. The SRC does so using the SIPREC defined SDP > attribute >> a=record. This attribute is used as a declaration by the SRC to > indicate >> whether recording of the CS is taking place . The SRC may use other > recording >> indication mechanisms as well; however, such mechanisms are outside > the scope >> of SIPREC. >> Recording-aware UAs can indicate a recording preference in the CS > using the >> SIPREC defined SDP attribute a=recordpref. The recording preference > attribute >> is a declaration by the recording-aware UA of its recording > preference. The >> SRC is not obligated to honor a recording preference provided by a UA, > as it >> is merely an indication of a preference, not a direct command or > request to >> start or stop recording." >> >> Cheers, >> Charles >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From pkyzivat@alum.mit.edu Thu Jul 26 13:32:24 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 E052C21F8598 for ; Thu, 26 Jul 2012 13:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.929 X-Spam-Level: X-Spam-Status: No, score=-0.929 tagged_above=-999 required=5 tests=[AWL=-1.092, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_110=0.6, RDNS_NONE=0.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 nPoh+pa6vDhr for ; Thu, 26 Jul 2012 13:32:24 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 27F1721F857D for ; Thu, 26 Jul 2012 13:32:23 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta02.westchester.pa.mail.comcast.net with comcast id eyoq1j0091GhbT8518YTqs; Thu, 26 Jul 2012 20:32:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id f8Ya1j00Z3ZTu2S3T8YaTy; Thu, 26 Jul 2012 20:32:34 +0000 Message-ID: <5011A956.5060700@alum.mit.edu> Date: Thu, 26 Jul 2012 16:32:22 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "siprec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [siprec] Comments on draft-ietf-siprec-protocol-06 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, 26 Jul 2012 20:32:25 -0000 Section 8.2.2: The SSRCs from the contributing UA SHOULD be conveyed as CSRCs identifiers within this stream. The SSRCs of the contributing UAs that are being mixed will typically come from independent RTP sessions, and so there could be collisions. The SRC must cope with this - perhaps by remapping SSRCs. Is the following from 8.3.2 intended to deal with this? In order to preserve the mapping of media to participant within the CSs in the RS, the SRC SHOULD map each unique combination of CNAME/ SSRC within the CSs to a unique SSRC within the RS. The CNAMEs used in the CSs are not preserved within the RS. The SRS relies on the SIPREC metadata to determine the participants included within each multiplexed stream. The SRC MUST avoid SSRC collisions, rewriting SSRCs if necessary. In doing to, the SRC acts as an RTP endpoint. But that has its own problems: - Do you really mean a unique SSRC within the *RS*??? In particular, if the SRC is recording many concurrent independent CSs, with each CS in a separate RTP session (m-line), must it assign unique SSRCs across all the RTP sessions? Or only across all the parts of the same CS? (There is similar language in 8.3.3 without these problems. Maybe it just needs to be used here too.) - If CNAMEs in the CSs aren't preserved in the RS, is there a 1:1 relation between them? If not, then sync between RTP streams in the CS won't be possible. If so, I guess it should be mentioned. In general, I think we need some discussion of what should happen if RTP stream multiplexing is being used within a single CS RTP session. ISTM that there should be a way for the SRC to convey enough info to the SRS so that it can understand how RTP streams were / weren't multiplexed in the CS and so reconstruct things properly. (OTOH I don't think the SRC need be REQUIRED to convey this much info.) Section 9.1: A full metadata snapshot describes all the recorded streams and all metadata associated with the recording session. This is fine as far as it goes. But I think it would helpful to say a bit more: A full metadata snapshot describes all the sessions, participants, streams subject to recording at the time of the snapshot, and all associated metadata. (I struggled with this. I hope it isn't too cumbersome.) My point is to indicate that this isn't expected to include historical data, such as sessions that were previously active but that have ended. Figure 12: It doesn't hurt, but its not necessary to list application/rs-metadata in the Accept. (Its only *sent*, not *received*.) Section 9.2: Note that the SRS MAY generate an INVITE request without an SDP offer but this MUST NOT include a metadata snapshot request. This seems wrong. Fix it by: s/without/with/ Section 11.1.1: If the a=recordpref attribute is omitted, then the recording preference would be assumed to be the recording preference set in a previous SDP offer or answer. I believe this to be unwise. One can never be certain that you are talking to the same entity as before. (There could have been a 3pcc transfer.) So I think we must assume that the lack of the attribute means lack of preference. Thanks, Paul From pkyzivat@alum.mit.edu Thu Jul 26 13:53: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 4D7D211E80B3 for ; Thu, 26 Jul 2012 13:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=0.307, 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 cAhauUtb86Zy for ; Thu, 26 Jul 2012 13:53:11 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id B0CBE11E8080 for ; Thu, 26 Jul 2012 13:53:11 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta08.westchester.pa.mail.comcast.net with comcast id f7aL1j0011swQuc588tERf; Thu, 26 Jul 2012 20:53:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id f8t21j0113ZTu2S3b8t2dX; Thu, 26 Jul 2012 20:53:03 +0000 Message-ID: <5011AE36.40406@alum.mit.edu> Date: Thu, 26 Jul 2012 16:53:10 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "siprec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [siprec] Comments on draft-ietf-siprec-architecture-05 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, 26 Jul 2012 20:53:12 -0000 One small comment on this: Section 3.2.4: When recording this media the two streams may be mixed at the SRC before being transmitted to the SRS or it may be a requirement of the recording server that the media streams are not mixed and are sent to the SRS as two separate streams. Do we really want to say that the SRS can decide that it must have unmixed media??? I don't think so. IMO this should be solely at the discretion of the SRC. If it was up to the SRS, how would it indicate this to the SRC? From leon.portman@gmail.com Thu Jul 26 13:59: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 373BF11E80B3 for ; Thu, 26 Jul 2012 13:59: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=[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 wEiYDNTIt3R3 for ; Thu, 26 Jul 2012 13:59:11 -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 5B46211E8080 for ; Thu, 26 Jul 2012 13:59:11 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so1791288wib.13 for ; Thu, 26 Jul 2012 13:59: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=gifQeTF1ggciLmK2QL5q+HtF/MZ9DjgqCQfjDEt5Of0=; b=eaD1x4tPSBtejTfZ11T5lIRg2Vko6P5ZLaT5p/bLrNc4zw8dV37BNofbmnCrT2eI28 xnrS0CZsek+D/R0FroFWoy5RAMNTeZEFjXVWS/AojrRwBqiOlq8iH+mT7v+78zifZ0B/ 4C5VwCDN06cigPOSF5/BhubZoCqUVdCmhV2BsapvaYfK7hx5r9gjQOM9LywwBp3YE4aX 9VgtQDVPxWRkmVOIfQPNbEbj3VNDpf7jqG6XdPI//eaRhowlzUMg/FWPZLxBKW5UJFmc 1//r1xRgpXSimZ3+hoaus5BA/Rsn4SLmW87N5XaVHNaAhlPoMaH5WW2GgQysYVaAevVS NZHQ== Received: by 10.216.23.202 with SMTP id v52mr97501wev.32.1343336350313; Thu, 26 Jul 2012 13:59:10 -0700 (PDT) Received: from [192.168.2.105] (46-116-44-105.bb.netvision.net.il. [46.116.44.105]) by mx.google.com with ESMTPS id k20sm10155024wiv.11.2012.07.26.13.59.08 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Jul 2012 13:59:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Leon Portman In-Reply-To: <5011AE36.40406@alum.mit.edu> Date: Thu, 26 Jul 2012 23:59:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5B5A7A9E-28C8-49A6-864B-FC4A334906A3@gmail.com> References: <5011AE36.40406@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1485) Cc: "siprec@ietf.org" Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 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, 26 Jul 2012 20:59:12 -0000 Paul Hi Generic comment: current implementations of SRS support to be configured = either store unmixed media separately or mixed them on SRS side in = order to save storage. On protocol side: we can define a negotiation of mixing like this: If = SRC supports sending both mixed and unmixed medias, it can offer both in = SDP as multiple m-lines and SRS can accept the preferred option. Of if it is specific policy on SRC side, SRS still can have option to = mix if SRC always sends unmixed. What do you think? Leon On Jul 26, 2012, at 11:53 PM, Paul Kyzivat = wrote: > One small comment on this: >=20 > Section 3.2.4: >=20 > When recording this media the two streams may be > mixed at the SRC before being transmitted to the SRS or it may be a > requirement of the recording server that the media streams are not > mixed and are sent to the SRS as two separate streams. >=20 > Do we really want to say that the SRS can decide that it must have = unmixed media??? >=20 > I don't think so. IMO this should be solely at the discretion of the = SRC. >=20 > If it was up to the SRS, how would it indicate this to the SRC? > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From prvs=1554f99b0c=MSmith@dss-corp.com Thu Jul 26 14:11: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 4FBAB21F855E for ; Thu, 26 Jul 2012 14:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 AUx47aHbp0ap for ; Thu, 26 Jul 2012 14:11:49 -0700 (PDT) Received: from spam.dss-corp.com (spam.dss-corp.com [67.214.118.46]) by ietfa.amsl.com (Postfix) with ESMTP id 512AD21F855D for ; Thu, 26 Jul 2012 14:11:49 -0700 (PDT) Received: from spam.dss-corp.com (127.0.0.1) by spam.dss-corp.com (MlfMTA v3.2r9) id h26q440171sk for ; Thu, 26 Jul 2012 17:18:58 -0400 (envelope-from ) Received: from exc.dss-corp.com ([192.168.1.5]) by spam.dss-corp.com (SonicWALL 7.2.4.3929) with ESMTP; Thu, 26 Jul 2012 17:18:57 -0400 Received: from EXC01.dss.lan ([fe80::109b:ad4:1a47:2813]) by exc01.dss.lan ([fe80::109b:ad4:1a47:2813%13]) with mapi; Thu, 26 Jul 2012 17:11:46 -0400 From: Michael Smith To: "siprec@ietf.org" Thread-Topic: [siprec] Comments on draft-ietf-siprec-architecture-05 Thread-Index: AQHNa3Czt4ZtpSjdMEe219lQXs2A+5c8TyqA//++Z2A= Date: Thu, 26 Jul 2012 21:11:24 +0000 Message-ID: <05D56509F27CCE4DAF8136C02386880D686C69AC@exc01.dss.lan> References: <5011AE36.40406@alum.mit.edu> <5B5A7A9E-28C8-49A6-864B-FC4A334906A3@gmail.com> In-Reply-To: <5B5A7A9E-28C8-49A6-864B-FC4A334906A3@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mlf-Version: 7.2.4.3929 X-Mlf-UniqueId: o201207262118570083522 Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 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, 26 Jul 2012 21:11:50 -0000 I would think you'd want the SRS, as the recipient of the media, to decide = whether it wants mixed or unmixed media. And that the SRC must support both= , and must comply with the SRS's request. And that implies that you must ha= ve a mechanism for the SRC to tell the SRC whether it wants mixed or unmixe= d media. An SRS may receive from many SRCs. What I suggest above allows policy to be= implemented in one place (the SRS), and forces all SRCs to comply with it.= =20 Michael Smith Chief Technologist Ph: 606.877.2788 | Mobile: 606.231.0243=20 DSS Corporation / Equature 18311=A0=A0 W. Ten Mile Road, Suite 200 Southfield, MI - 48075 Tel: 1-888.305.3428 Fax: 1-248.569.6567 www.dss-corp.com www.dispatchimprovement.com -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Leon Portman Sent: Thursday, July 26, 2012 4:59 PM To: Paul Kyzivat Cc: siprec@ietf.org Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 Paul Hi Generic comment: current implementations of SRS support to be configured ei= ther store unmixed media separately or mixed them on SRS side in order to = save storage. On protocol side: we can define a negotiation of mixing like this: If SRC s= upports sending both mixed and unmixed medias, it can offer both in SDP as = multiple m-lines and SRS can accept the preferred option. Of if it is specific policy on SRC side, SRS still can have option to mix i= f SRC always sends unmixed. What do you think? Leon On Jul 26, 2012, at 11:53 PM, Paul Kyzivat wrote: > One small comment on this: >=20 > Section 3.2.4: >=20 > When recording this media the two streams may be > mixed at the SRC before being transmitted to the SRS or it may be a > requirement of the recording server that the media streams are not > mixed and are sent to the SRS as two separate streams. >=20 > Do we really want to say that the SRS can decide that it must have unmixe= d media??? >=20 > I don't think so. IMO this should be solely at the discretion of the SRC. >=20 > If it was up to the SRS, how would it indicate this to the SRC? > _______________________________________________ > 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 Jul 26 14:11: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 2218021F8562 for ; Thu, 26 Jul 2012 14:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, 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 E-JNtdHTAI0M for ; Thu, 26 Jul 2012 14:11:57 -0700 (PDT) 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 71AC821F8540 for ; Thu, 26 Jul 2012 14:11:57 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta14.westchester.pa.mail.comcast.net with comcast id f76U1j0040Fqzac5E9C0t9; Thu, 26 Jul 2012 21:12:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id f9Bv1j00U3ZTu2S3U9BvyX; Thu, 26 Jul 2012 21:11:55 +0000 Message-ID: <5011B29C.9000101@alum.mit.edu> Date: Thu, 26 Jul 2012 17:11:56 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Leon Portman References: <5011AE36.40406@alum.mit.edu> <5B5A7A9E-28C8-49A6-864B-FC4A334906A3@gmail.com> In-Reply-To: <5B5A7A9E-28C8-49A6-864B-FC4A334906A3@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 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, 26 Jul 2012 21:11:58 -0000 On 7/26/12 4:59 PM, Leon Portman wrote: > Paul Hi > > Generic comment: current implementations of SRS support to be configured either store unmixed media separately or mixed them on SRS side in order to save storage. > On protocol side: we can define a negotiation of mixing like this: If SRC supports sending both mixed and unmixed medias, it can offer both in SDP as multiple m-lines and SRS can accept the preferred option. > Of if it is specific policy on SRC side, SRS still can have option to mix if SRC always sends unmixed. > > What do you think? I think its impossible to tell from the presence of m-lines whether the intent is to use them for independent streams in a session or independent sessions, or ???. *If* its necessary to negotiate mixing by the SRC, then I think we need to add some explicit mechanism to do it. But I'm not sure its necessary. Isn't it sufficient to leave the choice of which to do to local policy on the SRC? (And to require that an SRS be able to accept it either way.) Thanks, Paul > Leon > > On Jul 26, 2012, at 11:53 PM, Paul Kyzivat wrote: > >> One small comment on this: >> >> Section 3.2.4: >> >> When recording this media the two streams may be >> mixed at the SRC before being transmitted to the SRS or it may be a >> requirement of the recording server that the media streams are not >> mixed and are sent to the SRS as two separate streams. >> >> Do we really want to say that the SRS can decide that it must have unmixed media??? >> >> I don't think so. IMO this should be solely at the discretion of the SRC. >> >> If it was up to the SRS, how would it indicate this to the SRC? >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > > From eckelcu@cisco.com Thu Jul 26 14:52: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 38C8821F8535 for ; Thu, 26 Jul 2012 14:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.468 X-Spam-Level: X-Spam-Status: No, score=-10.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWRz82YyVdJk for ; Thu, 26 Jul 2012 14:52:03 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5629B21F8530 for ; Thu, 26 Jul 2012 14:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=3285; q=dns/txt; s=iport; t=1343339523; x=1344549123; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LuHCupIFrdDGP8XaTXwvvaSuL6luvfhe+6i2Z1du1Ks=; b=NQoL5BRQae7EWUAGLmIpjjxKVcIHt/xNpxbag5tFCvGKgHxIF9H73Mhx Jr7wfQYSXv/dQ6Q/PgWwrZS9shVVrzy+V0yV1Ti7yAs3duTuWEcglAjEu R3QIEOt+cq2hq8Wqn8jkFAiC+jZ9B5zU3mPrQiX/XPt6t9AYdDxSiOLbD s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADG7EVCtJV2a/2dsb2JhbABFDrksgQeCIAEBAQQBAQEPASc0CwwEAgEIDgMBAwEBAQoUCQcnCxQDBggCBAENBQgah2oBC5spoEEEi08ghXRgA6NvgWaCJjmBVw X-IronPort-AV: E=Sophos;i="4.77,662,1336348800"; d="scan'208";a="105745113" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 26 Jul 2012 21:52:02 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6QLq2b3000648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Jul 2012 21:52:02 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.205]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0298.004; Thu, 26 Jul 2012 16:52:02 -0500 From: "Charles Eckel (eckelcu)" To: Paul Kyzivat , Leon Portman Thread-Topic: [siprec] Comments on draft-ietf-siprec-architecture-05 Thread-Index: AQHNa3CumJm0k341mkCM7mdLdTpT5pc8X+6AgAADlQD//7a/UA== Date: Thu, 26 Jul 2012 21:52:02 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828045D40@xmb-aln-x08.cisco.com> References: <5011AE36.40406@alum.mit.edu> <5B5A7A9E-28C8-49A6-864B-FC4A334906A3@gmail.com> <5011B29C.9000101@alum.mit.edu> In-Reply-To: <5011B29C.9000101@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.122.35] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19066.001 x-tm-as-result: No--55.468100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 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, 26 Jul 2012 21:52:04 -0000 I ran into this when adding the "RTP Session Usage by SRC" section to the p= rotocol draft. Here an example of how I handled it: When using multiple m-lines, an SRC includes each m-line in an SDP offer to the SRS. The SDP answer from the SRS MUST include all m-lines, with any rejected m-lines indicated with a zero port, per [RFC3264]. Having received the answer, the SRC starts sending media to the SRS as indicated in the answer. Alternatively, if the SRC deems the level of support indicated in the answer to be unacceptable, it may initiate another SDP offer/answer exchange in which an alternative RTP session usage is negotiated. If we think we need something more explicit, or something that works with a= single offer/answer exchange, we need to add a new mechanism to the protoc= ol. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Thursday, July 26, 2012 2:12 PM > To: Leon Portman > Cc: siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >=20 > On 7/26/12 4:59 PM, Leon Portman wrote: > > Paul Hi > > > > Generic comment: current implementations of SRS support to be > configured either store unmixed media separately or mixed them on SRS > side in order to save storage. > > On protocol side: we can define a negotiation of mixing like this: If S= RC > supports sending both mixed and unmixed medias, it can offer both in SDP > as multiple m-lines and SRS can accept the preferred option. > > Of if it is specific policy on SRC side, SRS still can have option to m= ix if SRC > always sends unmixed. > > > > What do you think? >=20 > I think its impossible to tell from the presence of m-lines whether the > intent is to use them for independent streams in a session or > independent sessions, or ???. >=20 > *If* its necessary to negotiate mixing by the SRC, then I think we need > to add some explicit mechanism to do it. But I'm not sure its necessary. > Isn't it sufficient to leave the choice of which to do to local policy > on the SRC? (And to require that an SRS be able to accept it either way.) >=20 > Thanks, > Paul >=20 > > Leon > > > > On Jul 26, 2012, at 11:53 PM, Paul Kyzivat wrot= e: > > > >> One small comment on this: > >> > >> Section 3.2.4: > >> > >> When recording this media the two streams may be > >> mixed at the SRC before being transmitted to the SRS or it may be a > >> requirement of the recording server that the media streams are not > >> mixed and are sent to the SRS as two separate streams. > >> > >> Do we really want to say that the SRS can decide that it must have > unmixed media??? > >> > >> I don't think so. IMO this should be solely at the discretion of the S= RC. > >> > >> If it was up to the SRS, how would it indicate this to the SRC? > >> _______________________________________________ > >> 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 pkyzivat@alum.mit.edu Thu Jul 26 15:15: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 C659621F8484 for ; Thu, 26 Jul 2012 15:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=0.297, 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 8KhwvRyHf6Kt for ; Thu, 26 Jul 2012 15:15:02 -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 6389E21F848A for ; Thu, 26 Jul 2012 15:15:02 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta03.westchester.pa.mail.comcast.net with comcast id f93D1j00P0bG4ec53AF5eq; Thu, 26 Jul 2012 22:15:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id fAF21j00t3ZTu2S3PAF2pX; Thu, 26 Jul 2012 22:15:02 +0000 Message-ID: <5011C164.1080600@alum.mit.edu> Date: Thu, 26 Jul 2012 18:15:00 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <5011AE36.40406@alum.mit.edu> <5B5A7A9E-28C8-49A6-864B-FC4A334906A3@gmail.com> <05D56509F27CCE4DAF8136C02386880D686C69AC@exc01.dss.lan> In-Reply-To: <05D56509F27CCE4DAF8136C02386880D686C69AC@exc01.dss.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 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, 26 Jul 2012 22:15:04 -0000 On 7/26/12 5:11 PM, Michael Smith wrote: > I would think you'd want the SRS, as the recipient of the media, to decide whether it wants mixed or unmixed media. And that the SRC must support both, and must comply with the SRS's request. And that implies that you must have a mechanism for the SRC to tell the SRC whether it wants mixed or unmixed media. You are going to *require* that the SRC be able to do mixing??? > An SRS may receive from many SRCs. What I suggest above allows policy to be implemented in one place (the SRS), and forces all SRCs to comply with it. On the contrary, ISTM that the SRS is a *utility*, and one that probably has considerable resources. It is providing a service to a wide range of clients that may vary widely in their capabilities. It makes much or sense to me that life is made as simple and flexible as possible for the SRC. Leon indicated that some preliminary implementations prefer to receive the streams unmixed. That is also perhaps easier for the SRC, at the expense of requiring more bandwidth. Certainly its easier for a "phone" that might have no mixing capability at all. OTOH there may be devices that are very bandwidth limited that would prefer to mix first to conserve the bandwidth. And there may be some devices, such as a conference focus, for which mixing may be the most convenient way. And of course there could be an SRC that is a *participant* in a conference, that has no choice but to accept mixed media from the focus, and so must pass it along unmixed to the SRS. Thanks, Paul > Michael Smith > Chief Technologist > Ph: 606.877.2788 | Mobile: 606.231.0243 > > DSS Corporation / Equature > 18311 W. Ten Mile Road, Suite 200 > Southfield, MI - 48075 > Tel: 1-888.305.3428 > Fax: 1-248.569.6567 > www.dss-corp.com > www.dispatchimprovement.com > > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman > Sent: Thursday, July 26, 2012 4:59 PM > To: Paul Kyzivat > Cc: siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > > Paul Hi > > Generic comment: current implementations of SRS support to be configured either store unmixed media separately or mixed them on SRS side in order to save storage. > On protocol side: we can define a negotiation of mixing like this: If SRC supports sending both mixed and unmixed medias, it can offer both in SDP as multiple m-lines and SRS can accept the preferred option. > Of if it is specific policy on SRC side, SRS still can have option to mix if SRC always sends unmixed. > > What do you think? > > > Leon > > On Jul 26, 2012, at 11:53 PM, Paul Kyzivat wrote: > >> One small comment on this: >> >> Section 3.2.4: >> >> When recording this media the two streams may be >> mixed at the SRC before being transmitted to the SRS or it may be a >> requirement of the recording server that the media streams are not >> mixed and are sent to the SRS as two separate streams. >> >> Do we really want to say that the SRS can decide that it must have unmixed media??? >> >> I don't think so. IMO this should be solely at the discretion of the SRC. >> >> If it was up to the SRS, how would it indicate this to the SRC? >> _______________________________________________ >> 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 prvs=1554f99b0c=MSmith@dss-corp.com Thu Jul 26 16:08:51 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 6938821F852C for ; Thu, 26 Jul 2012 16:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 Y0FLF6jpT3dh for ; Thu, 26 Jul 2012 16:08:50 -0700 (PDT) Received: from spam.dss-corp.com (spam.dss-corp.com [67.214.118.46]) by ietfa.amsl.com (Postfix) with ESMTP id 759F121F851C for ; Thu, 26 Jul 2012 16:08:50 -0700 (PDT) Received: from spam.dss-corp.com (127.0.0.1) by spam.dss-corp.com (MlfMTA v3.2r9) id h277r00171sj for ; Thu, 26 Jul 2012 19:15:58 -0400 (envelope-from ) Received: from exc.dss-corp.com ([192.168.1.5]) by spam.dss-corp.com (SonicWALL 7.2.4.3929) with ESMTP; Thu, 26 Jul 2012 19:15:58 -0400 Received: from EXC01.dss.lan ([fe80::109b:ad4:1a47:2813]) by exc01.dss.lan ([fe80::109b:ad4:1a47:2813%13]) with mapi; Thu, 26 Jul 2012 19:08:49 -0400 From: Michael Smith To: "siprec@ietf.org" Thread-Topic: [siprec] Comments on draft-ietf-siprec-architecture-05 Thread-Index: AQHNa3Czt4ZtpSjdMEe219lQXs2A+5c8TyqA//++Z2CAAFbNAP//xgFg Date: Thu, 26 Jul 2012 23:08:28 +0000 Message-ID: <05D56509F27CCE4DAF8136C02386880D686C7410@exc01.dss.lan> References: <5011AE36.40406@alum.mit.edu> <5B5A7A9E-28C8-49A6-864B-FC4A334906A3@gmail.com> <05D56509F27CCE4DAF8136C02386880D686C69AC@exc01.dss.lan> <5011C164.1080600@alum.mit.edu> In-Reply-To: <5011C164.1080600@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mlf-Version: 7.2.4.3929 X-Mlf-UniqueId: o201207262315580083828 Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 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, 26 Jul 2012 23:08:51 -0000 Hmmm... What's important is that the SRC supports unmixed streams. If it do= es, the server could mix them, and policy is enforced at that point. The dr= awback to that is that you consume twice the bandwidth per CS, even if your= policy is to store mixed streams.=20 Good point about a phone, but they do already mix the two parties voices. M= ixing is simple, and not processing-intensive, so levying that requirement = on an SRC isn't onerous, IMHO. I'd be ok if an SRC didn't support mixing media, and the SRS mixed it. But = I think it's a problem if an SRC mixes media and policy dictates that unmix= ed media be stored - there's no way to un-mix it.=20 I think requirements might be crafted that an SRS MUST support receiving bo= th mixed and unmixed media, and an SRC MUST support sending unmixed media, = and MAY support sending mixed media. You'd still need some mechanism for ne= gotiating mixed/unmixed. Michael Smith Chief Technologist Ph: 606.877.2788 | Mobile: 606.231.0243=20 DSS Corporation / Equature 18311=A0=A0 W. Ten Mile Road, Suite 200 Southfield, MI - 48075 Tel: 1-888.305.3428 Fax: 1-248.569.6567 www.dss-corp.com www.dispatchimprovement.com -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: Thursday, July 26, 2012 6:15 PM To: siprec@ietf.org Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 On 7/26/12 5:11 PM, Michael Smith wrote: > I would think you'd want the SRS, as the recipient of the media, to decid= e whether it wants mixed or unmixed media. And that the SRC must support bo= th, and must comply with the SRS's request. And that implies that you must = have a mechanism for the SRC to tell the SRC whether it wants mixed or unmi= xed media. You are going to *require* that the SRC be able to do mixing??? > An SRS may receive from many SRCs. What I suggest above allows policy to = be implemented in one place (the SRS), and forces all SRCs to comply with i= t. On the contrary, ISTM that the SRS is a *utility*, and one that probably ha= s considerable resources. It is providing a service to a wide range of clie= nts that may vary widely in their capabilities. It makes much or sense to me that life is made as simple and flexible as po= ssible for the SRC. Leon indicated that some preliminary implementations prefer to receive the = streams unmixed. That is also perhaps easier for the SRC, at the expense of= requiring more bandwidth. Certainly its easier for a "phone"=20 that might have no mixing capability at all. OTOH there may be devices that= are very bandwidth limited that would prefer to mix first to conserve the = bandwidth. And there may be some devices, such as a conference focus, for w= hich mixing may be the most convenient way. And of course there could be an= SRC that is a *participant* in a conference, that has no choice but to acc= ept mixed media from the focus, and so must pass it along unmixed to the SR= S. Thanks, Paul > Michael Smith > Chief Technologist > Ph: 606.877.2788 | Mobile: 606.231.0243 > > DSS Corporation / Equature > 18311 W. Ten Mile Road, Suite 200 > Southfield, MI - 48075 > Tel: 1-888.305.3428 > Fax: 1-248.569.6567 > www.dss-corp.com > www.dispatchimprovement.com > > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Leon Portman > Sent: Thursday, July 26, 2012 4:59 PM > To: Paul Kyzivat > Cc: siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > > Paul Hi > > Generic comment: current implementations of SRS support to be configured = either store unmixed media separately or mixed them on SRS side in order t= o save storage. > On protocol side: we can define a negotiation of mixing like this: If SRC= supports sending both mixed and unmixed medias, it can offer both in SDP a= s multiple m-lines and SRS can accept the preferred option. > Of if it is specific policy on SRC side, SRS still can have option to mix= if SRC always sends unmixed. > > What do you think? > > > Leon > > On Jul 26, 2012, at 11:53 PM, Paul Kyzivat wrote: > >> One small comment on this: >> >> Section 3.2.4: >> >> When recording this media the two streams may be >> mixed at the SRC before being transmitted to the SRS or it may be a >> requirement of the recording server that the media streams are not >> mixed and are sent to the SRS as two separate streams. >> >> Do we really want to say that the SRS can decide that it must have unmix= ed media??? >> >> I don't think so. IMO this should be solely at the discretion of the SRC= . >> >> If it was up to the SRS, how would it indicate this to the SRC? >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Thu Jul 26 17:34: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 437AC11E80B3 for ; Thu, 26 Jul 2012 17:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 y4mNPEEKDYN4 for ; Thu, 26 Jul 2012 17:34:35 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 55AA211E8086 for ; Thu, 26 Jul 2012 17:34:24 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta02.westchester.pa.mail.comcast.net with comcast id fCPe1j0070EZKEL51CaT02; Fri, 27 Jul 2012 00:34:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2002:328a:e5a4:0:3c94:a930:dc7f:3e91]) by omta01.westchester.pa.mail.comcast.net with comcast id fCaa1j0044oZZXY3MCaane; Fri, 27 Jul 2012 00:34:35 +0000 Message-ID: <5011E20F.10804@alum.mit.edu> Date: Thu, 26 Jul 2012 20:34:23 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <5011AE36.40406@alum.mit.edu> <5B5A7A9E-28C8-49A6-864B-FC4A334906A3@gmail.com> <5011B29C.9000101@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C08828045D40@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828045D40@xmb-aln-x08.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 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, 27 Jul 2012 00:34:37 -0000 On 7/26/12 5:52 PM, Charles Eckel (eckelcu) wrote: > I ran into this when adding the "RTP Session Usage by SRC" section to the protocol draft. Here an example of how I handled it: > > When using multiple m-lines, an SRC includes each m-line in an SDP > offer to the SRS. The SDP answer from the SRS MUST include all > m-lines, with any rejected m-lines indicated with a zero port, per > [RFC3264]. Having received the answer, the SRC starts sending media > to the SRS as indicated in the answer. Alternatively, if the SRC > deems the level of support indicated in the answer to be > unacceptable, it may initiate another SDP offer/answer exchange in > which an alternative RTP session usage is negotiated. > > If we think we need something more explicit, or something that works with a single offer/answer exchange, we need to add a new mechanism to the protocol. Well, this only touches on the issue. I guess it is true that the SRS could refuse all but one m-line (or one audio and one video). And then the SRC would be forced to cope with that. But that would force it to mix or multiplex on the one. But it could do that for one CS and establish a separate RS for every CS. But that is an extreme. Other possibilities are to multiplex/mix all the all of one CS on one m-line, but have multiple m-lines, one for each CS. Or it could multiplex many CS on a single m-line. If the SRS gets to have an opinion on this it will get complicated. ISTM that its better to just say this is up to the SRC to decide. The SRS can still limit the total number of m-lines, but not how they are used. Thanks, Paul > Cheers, > Charles > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Thursday, July 26, 2012 2:12 PM >> To: Leon Portman >> Cc: siprec@ietf.org >> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >> >> On 7/26/12 4:59 PM, Leon Portman wrote: >>> Paul Hi >>> >>> Generic comment: current implementations of SRS support to be >> configured either store unmixed media separately or mixed them on SRS >> side in order to save storage. >>> On protocol side: we can define a negotiation of mixing like this: If SRC >> supports sending both mixed and unmixed medias, it can offer both in SDP >> as multiple m-lines and SRS can accept the preferred option. >>> Of if it is specific policy on SRC side, SRS still can have option to mix if SRC >> always sends unmixed. >>> >>> What do you think? >> >> I think its impossible to tell from the presence of m-lines whether the >> intent is to use them for independent streams in a session or >> independent sessions, or ???. >> >> *If* its necessary to negotiate mixing by the SRC, then I think we need >> to add some explicit mechanism to do it. But I'm not sure its necessary. >> Isn't it sufficient to leave the choice of which to do to local policy >> on the SRC? (And to require that an SRS be able to accept it either way.) >> >> Thanks, >> Paul >> >>> Leon >>> >>> On Jul 26, 2012, at 11:53 PM, Paul Kyzivat wrote: >>> >>>> One small comment on this: >>>> >>>> Section 3.2.4: >>>> >>>> When recording this media the two streams may be >>>> mixed at the SRC before being transmitted to the SRS or it may be a >>>> requirement of the recording server that the media streams are not >>>> mixed and are sent to the SRS as two separate streams. >>>> >>>> Do we really want to say that the SRS can decide that it must have >> unmixed media??? >>>> >>>> I don't think so. IMO this should be solely at the discretion of the SRC. >>>> >>>> If it was up to the SRS, how would it indicate this to the SRC? >>>> _______________________________________________ >>>> 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 Jul 26 17:46: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 0C3B811E80C9 for ; Thu, 26 Jul 2012 17:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.306 X-Spam-Level: X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[AWL=0.293, 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 aXj8-D6CPKYS for ; Thu, 26 Jul 2012 17:46:40 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id B279911E80A2 for ; Thu, 26 Jul 2012 17:46:39 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta05.westchester.pa.mail.comcast.net with comcast id f01i1j00227AodY55Cmiw6; Fri, 27 Jul 2012 00:46:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id fCmr1j00a3ZTu2S3fCmr1x; Fri, 27 Jul 2012 00:46:52 +0000 Message-ID: <5011E4ED.1080101@alum.mit.edu> Date: Thu, 26 Jul 2012 20:46:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <5011AE36.40406@alum.mit.edu> <5B5A7A9E-28C8-49A6-864B-FC4A334906A3@gmail.com> <05D56509F27CCE4DAF8136C02386880D686C69AC@exc01.dss.lan> <5011C164.1080600@alum.mit.edu> <05D56509F27CCE4DAF8136C02386880D686C7410@exc01.dss.lan> In-Reply-To: <05D56509F27CCE4DAF8136C02386880D686C7410@exc01.dss.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 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, 27 Jul 2012 00:46:41 -0000 On 7/26/12 7:08 PM, Michael Smith wrote: > Hmmm... What's important is that the SRC supports unmixed streams. If it does, the server could mix them, and policy is enforced at that point. The drawback to that is that you consume twice the bandwidth per CS, even if your policy is to store mixed streams. > > Good point about a phone, but they do already mix the two parties voices. Mixing is simple, and not processing-intensive, so levying that requirement on an SRC isn't onerous, IMHO. > > I'd be ok if an SRC didn't support mixing media, and the SRS mixed it. But I think it's a problem if an SRC mixes media and policy dictates that unmixed media be stored - there's no way to un-mix it. So what about an SRC connected to a focus of a conference with many participants. The SRC is only receiving a mixed stream from the focus, which includes all participants except itself. It can know who all the participants are (from the conference event package), but it can't pass them on unmixed. > I think requirements might be crafted that an SRS MUST support receiving both mixed and unmixed media, and an SRC MUST support sending unmixed media, and MAY support sending mixed media. You'd still need some mechanism for negotiating mixed/unmixed. I'm going to stand by my prior opinion for now. As a customer I think you can *prefer* that things work this way. If you have buying control over the SRC you can specify that. But I don't think it makes sense to exclude SRCs that work otherwise. Thanks, Paul > Michael Smith > Chief Technologist > Ph: 606.877.2788 | Mobile: 606.231.0243 > > DSS Corporation / Equature > 18311 W. Ten Mile Road, Suite 200 > Southfield, MI - 48075 > Tel: 1-888.305.3428 > Fax: 1-248.569.6567 > www.dss-corp.com > www.dispatchimprovement.com > > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Thursday, July 26, 2012 6:15 PM > To: siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > > On 7/26/12 5:11 PM, Michael Smith wrote: >> I would think you'd want the SRS, as the recipient of the media, to decide whether it wants mixed or unmixed media. And that the SRC must support both, and must comply with the SRS's request. And that implies that you must have a mechanism for the SRC to tell the SRC whether it wants mixed or unmixed media. > > You are going to *require* that the SRC be able to do mixing??? > >> An SRS may receive from many SRCs. What I suggest above allows policy to be implemented in one place (the SRS), and forces all SRCs to comply with it. > > On the contrary, ISTM that the SRS is a *utility*, and one that probably has considerable resources. It is providing a service to a wide range of clients that may vary widely in their capabilities. > It makes much or sense to me that life is made as simple and flexible as possible for the SRC. > > Leon indicated that some preliminary implementations prefer to receive the streams unmixed. That is also perhaps easier for the SRC, at the expense of requiring more bandwidth. Certainly its easier for a "phone" > that might have no mixing capability at all. OTOH there may be devices that are very bandwidth limited that would prefer to mix first to conserve the bandwidth. And there may be some devices, such as a conference focus, for which mixing may be the most convenient way. And of course there could be an SRC that is a *participant* in a conference, that has no choice but to accept mixed media from the focus, and so must pass it along unmixed to the SRS. > > Thanks, > Paul > >> Michael Smith >> Chief Technologist >> Ph: 606.877.2788 | Mobile: 606.231.0243 >> >> DSS Corporation / Equature >> 18311 W. Ten Mile Road, Suite 200 >> Southfield, MI - 48075 >> Tel: 1-888.305.3428 >> Fax: 1-248.569.6567 >> www.dss-corp.com >> www.dispatchimprovement.com >> >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Leon Portman >> Sent: Thursday, July 26, 2012 4:59 PM >> To: Paul Kyzivat >> Cc: siprec@ietf.org >> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >> >> Paul Hi >> >> Generic comment: current implementations of SRS support to be configured either store unmixed media separately or mixed them on SRS side in order to save storage. >> On protocol side: we can define a negotiation of mixing like this: If SRC supports sending both mixed and unmixed medias, it can offer both in SDP as multiple m-lines and SRS can accept the preferred option. >> Of if it is specific policy on SRC side, SRS still can have option to mix if SRC always sends unmixed. >> >> What do you think? >> >> >> Leon >> >> On Jul 26, 2012, at 11:53 PM, Paul Kyzivat wrote: >> >>> One small comment on this: >>> >>> Section 3.2.4: >>> >>> When recording this media the two streams may be >>> mixed at the SRC before being transmitted to the SRS or it may be a >>> requirement of the recording server that the media streams are not >>> mixed and are sent to the SRS as two separate streams. >>> >>> Do we really want to say that the SRS can decide that it must have unmixed media??? >>> >>> I don't think so. IMO this should be solely at the discretion of the SRC. >>> >>> If it was up to the SRS, how would it indicate this to the SRC? >>> _______________________________________________ >>> 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 Thu Jul 26 21:44:51 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 65EF111E80B7 for ; Thu, 26 Jul 2012 21:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 usr2B6LyBLBm for ; Thu, 26 Jul 2012 21:44:50 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2E811E8073 for ; Thu, 26 Jul 2012 21:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=7052; q=dns/txt; s=iport; t=1343364290; x=1344573890; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=5hd12WN07QdjGiLsaQitWN9+WXS28RXA/COHL0aMI5w=; b=VDIXC5exu54Yp433fjGzs2mNfAUQTee1eNXNbFqp1Hyr3DHUpjXE3Aqn yLJcxfme8k1khwv1S6cOR7T9Ou/cqTrJyX6fcVe5QFNUZxK8RupuUG+zI 5neD4slMMFJ4C0ia6JBTFsdqIl4jzxrN1wRlUtO6tX/1R90GEyCNj6d9R Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPkbElCtJXG+/2dsb2JhbABCAw65JYEHgiABAQEDAQEBAQ8BJw8fBhAHBgEIDgMBAwEBAR4JLgsUAwYIAgQBEhkJh2UGC5sroDmLTwoKDIMzgyEDlUiOJ4FmgiY5gVYB X-IronPort-AV: E=Sophos;i="4.77,664,1336348800"; d="scan'208";a="105818699" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 27 Jul 2012 04:44:49 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6R4inn2025434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Jul 2012 04:44:49 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.114]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0298.004; Thu, 26 Jul 2012 23:44:48 -0500 From: "Ram Mohan R (rmohanr)" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] Comments on draft-ietf-siprec-architecture-05 Thread-Index: AQHNa7KN+wWFLuL1TEKcGcfE7pvIhg== Date: Fri, 27 Jul 2012 04:44:47 +0000 Message-ID: In-Reply-To: <5011E4ED.1080101@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [173.39.68.59] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19066.001 x-tm-as-result: No--60.161300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <8B695BB2A89F4745A98147884174A68D@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 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, 27 Jul 2012 04:44:51 -0000 > On 27/07/12 6:16 AM, "Paul Kyzivat" wrote: >On 7/26/12 7:08 PM, Michael Smith wrote: >> Hmmm... What's important is that the SRC supports unmixed streams. If >>it does, the server could mix them, and policy is enforced at that >>point. The drawback to that is that you consume twice the bandwidth per >>CS, even if your policy is to store mixed streams. >> >> Good point about a phone, but they do already mix the two parties >>voices. Mixing is simple, and not processing-intensive, so levying that >>requirement on an SRC isn't onerous, IMHO. >> >> I'd be ok if an SRC didn't support mixing media, and the SRS mixed it. >>But I think it's a problem if an SRC mixes media and policy dictates >>that unmixed media be stored - there's no way to un-mix it. > >So what about an SRC connected to a focus of a conference with many >participants. The SRC is only receiving a mixed stream from the focus, >which includes all participants except itself. It can know who all the >participants are (from the conference event package), but it can't pass >them on unmixed. > >> I think requirements might be crafted that an SRS MUST support >>receiving both mixed and unmixed media, and an SRC MUST support sending >>unmixed media, and MAY support sending mixed media. You'd still need >>some mechanism for negotiating mixed/unmixed. > >I'm going to stand by my prior opinion for now. > >As a customer I think you can *prefer* that things work this way. If you >have buying control over the SRC you can specify that. But I don't think >it makes sense to exclude SRCs that work otherwise. I also agree with Paul. We can have an SRC that does one or more of the following: 1)An SRC MAY support sending unmixed media only 2) An SRC supports sending mixed media only (the case of conference where SRC is a participant) 3) An SRC supports sending mixed or unmixed media or both So its better not to restrict and there by exclude some SRCs. Ram > > Thanks, > Paul > >> Michael Smith >> Chief Technologist >> Ph: 606.877.2788 | Mobile: 606.231.0243 >> >> DSS Corporation / Equature >> 18311 W. Ten Mile Road, Suite 200 >> Southfield, MI - 48075 >> Tel: 1-888.305.3428 >> Fax: 1-248.569.6567 >> www.dss-corp.com >> www.dispatchimprovement.com >> >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>Behalf Of Paul Kyzivat >> Sent: Thursday, July 26, 2012 6:15 PM >> To: siprec@ietf.org >> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >> >> On 7/26/12 5:11 PM, Michael Smith wrote: >>> I would think you'd want the SRS, as the recipient of the media, to >>>decide whether it wants mixed or unmixed media. And that the SRC must >>>support both, and must comply with the SRS's request. And that implies >>>that you must have a mechanism for the SRC to tell the SRC whether it >>>wants mixed or unmixed media. >> >> You are going to *require* that the SRC be able to do mixing??? >> >>> An SRS may receive from many SRCs. What I suggest above allows policy >>>to be implemented in one place (the SRS), and forces all SRCs to comply >>>with it. >> >> On the contrary, ISTM that the SRS is a *utility*, and one that >>probably has considerable resources. It is providing a service to a wide >>range of clients that may vary widely in their capabilities. >> It makes much or sense to me that life is made as simple and flexible >>as possible for the SRC. >> >> Leon indicated that some preliminary implementations prefer to receive >>the streams unmixed. That is also perhaps easier for the SRC, at the >>expense of requiring more bandwidth. Certainly its easier for a "phone" >> that might have no mixing capability at all. OTOH there may be devices >>that are very bandwidth limited that would prefer to mix first to >>conserve the bandwidth. And there may be some devices, such as a >>conference focus, for which mixing may be the most convenient way. And >>of course there could be an SRC that is a *participant* in a conference, >>that has no choice but to accept mixed media from the focus, and so must >>pass it along unmixed to the SRS. >> >> Thanks, >> Paul >> >>> Michael Smith >>> Chief Technologist >>> Ph: 606.877.2788 | Mobile: 606.231.0243 >>> >>> DSS Corporation / Equature >>> 18311 W. Ten Mile Road, Suite 200 >>> Southfield, MI - 48075 >>> Tel: 1-888.305.3428 >>> Fax: 1-248.569.6567 >>> www.dss-corp.com >>> www.dispatchimprovement.com >>> >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Leon Portman >>> Sent: Thursday, July 26, 2012 4:59 PM >>> To: Paul Kyzivat >>> Cc: siprec@ietf.org >>> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >>> >>> Paul Hi >>> >>> Generic comment: current implementations of SRS support to be >>>configured either store unmixed media separately or mixed them on SRS >>>side in order to save storage. >>> On protocol side: we can define a negotiation of mixing like this: If >>>SRC supports sending both mixed and unmixed medias, it can offer both >>>in SDP as multiple m-lines and SRS can accept the preferred option. >>> Of if it is specific policy on SRC side, SRS still can have option to >>>mix if SRC always sends unmixed. >>> >>> What do you think? >>> >>> >>> Leon >>> >>> On Jul 26, 2012, at 11:53 PM, Paul Kyzivat >>>wrote: >>> >>>> One small comment on this: >>>> >>>> Section 3.2.4: >>>> >>>> When recording this media the two streams may be >>>> mixed at the SRC before being transmitted to the SRS or it may be >>>>a >>>> requirement of the recording server that the media streams are not >>>> mixed and are sent to the SRS as two separate streams. >>>> >>>> Do we really want to say that the SRS can decide that it must have >>>>unmixed media??? >>>> >>>> I don't think so. IMO this should be solely at the discretion of the >>>>SRC. >>>> >>>> If it was up to the SRS, how would it indicate this to the SRC? >>>> _______________________________________________ >>>> 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 prvs=1555156da9=MSmith@dss-corp.com Fri Jul 27 06:28: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 391BD21F8691 for ; Fri, 27 Jul 2012 06:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 odvaQT6fx8O3 for ; Fri, 27 Jul 2012 06:28:42 -0700 (PDT) Received: from spam.dss-corp.com (spam.dss-corp.com [67.214.118.46]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCB221F8688 for ; Fri, 27 Jul 2012 06:28:42 -0700 (PDT) Received: from spam.dss-corp.com (127.0.0.1) by spam.dss-corp.com (MlfMTA v3.2r9) id h2acji0171sf for ; Fri, 27 Jul 2012 09:35:52 -0400 (envelope-from ) Received: from exc.dss-corp.com ([192.168.1.5]) by spam.dss-corp.com (SonicWALL 7.2.4.3929) with ESMTP; Fri, 27 Jul 2012 09:35:51 -0400 Received: from EXC01.dss.lan ([fe80::109b:ad4:1a47:2813]) by exc01.dss.lan ([fe80::109b:ad4:1a47:2813%13]) with mapi; Fri, 27 Jul 2012 09:28:39 -0400 From: Michael Smith To: "siprec@ietf.org" Thread-Topic: [siprec] Comments on draft-ietf-siprec-architecture-05 Thread-Index: AQHNa3Czt4ZtpSjdMEe219lQXs2A+5c8TyqA//++Z2CAAFbNAP//xgFggABkW4CAAEKLgIAASdxQ Date: Fri, 27 Jul 2012 13:28:17 +0000 Message-ID: <05D56509F27CCE4DAF8136C02386880D686CBD5A@exc01.dss.lan> References: <5011E4ED.1080101@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mlf-Version: 7.2.4.3929 X-Mlf-UniqueId: o201207271335510085481 Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 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, 27 Jul 2012 13:28:44 -0000 So Ram proposes: We can have an SRC that does one or more of the following: 1)An SRC MAY support sending unmixed media only 2) An SRC supports sending mixed media only (the case of conference whe= re SRC is a participant) 3) An SRC supports sending mixed or unmixed media or both I'm curious - do others agree with that position? IMHO, the SRC conference participant case is a non-issue. If an SRC is a pa= rticipant in a Bridge, the "mixed" media coming from the Bridge is a single= stream from its point of view, and an SRS that wanted unmixed media would = only get whatever streams the SRC had.=20 Now, I would like to see the possibility of the SRS dictating (or at least = indicating a desire for) mixed or unmixed media, but if the majority disagr= ee, I can live with that. I do want to bring this up with the NENA NG9-1-1 recording test committee I= chair. Nine recording companies participate, and I'd like to see if that g= roup thinks we should impose additional requirements for an SRC/SRS used in= an NG9-1-1 environment. I don't personally think that Public Safety needs = are different than private sector needs on this issue, but it's a good disc= ussion to have now. If there were no mechanism for the SRS to make its mixe= d/unmixed desire known, we'd have a problem to solve. Perhaps this group co= uld define such a mechanism without requiring that it be used? Thanks, Michael Smith Chief Technologist Ph: 606.877.2788 | Mobile: 606.231.0243=20 DSS Corporation / Equature 18311=A0=A0 W. Ten Mile Road, Suite 200 Southfield, MI - 48075 Tel: 1-888.305.3428 Fax: 1-248.569.6567 www.dss-corp.com www.dispatchimprovement.com -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Ram Mohan R (rmohanr) Sent: Friday, July 27, 2012 12:45 AM To: Paul Kyzivat; siprec@ietf.org Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > On 27/07/12 6:16 AM, "Paul Kyzivat" wrote: >On 7/26/12 7:08 PM, Michael Smith wrote: >> Hmmm... What's important is that the SRC supports unmixed streams. If=20 >>it does, the server could mix them, and policy is enforced at that=20 >>point. The drawback to that is that you consume twice the bandwidth=20 >>per CS, even if your policy is to store mixed streams. >> >> Good point about a phone, but they do already mix the two parties=20 >>voices. Mixing is simple, and not processing-intensive, so levying=20 >>that requirement on an SRC isn't onerous, IMHO. >> >> I'd be ok if an SRC didn't support mixing media, and the SRS mixed it. >>But I think it's a problem if an SRC mixes media and policy dictates=20 >>that unmixed media be stored - there's no way to un-mix it. > >So what about an SRC connected to a focus of a conference with many=20 >participants. The SRC is only receiving a mixed stream from the focus,=20 >which includes all participants except itself. It can know who all the=20 >participants are (from the conference event package), but it can't pass=20 >them on unmixed. > >> I think requirements might be crafted that an SRS MUST support=20 >>receiving both mixed and unmixed media, and an SRC MUST support=20 >>sending unmixed media, and MAY support sending mixed media. You'd=20 >>still need some mechanism for negotiating mixed/unmixed. > >I'm going to stand by my prior opinion for now. > >As a customer I think you can *prefer* that things work this way. If=20 >you have buying control over the SRC you can specify that. But I don't=20 >think it makes sense to exclude SRCs that work otherwise. I also agree with Paul. We can have an SRC that does one or more of the following: 1)An SRC MAY support sending unmixed media only 2) An SRC supports sending mixed media only (the case of conference where S= RC is a participant) 3) An SRC supports sending mixed or unmixed media or both So its better not to restrict and there by exclude some SRCs. Ram > > Thanks, > Paul > >> Michael Smith >> Chief Technologist >> Ph: 606.877.2788 | Mobile: 606.231.0243 >> >> DSS Corporation / Equature >> 18311 W. Ten Mile Road, Suite 200 >> Southfield, MI - 48075 >> Tel: 1-888.305.3428 >> Fax: 1-248.569.6567 >> www.dss-corp.com >> www.dispatchimprovement.com >> >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>Behalf Of Paul Kyzivat >> Sent: Thursday, July 26, 2012 6:15 PM >> To: siprec@ietf.org >> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >> >> On 7/26/12 5:11 PM, Michael Smith wrote: >>> I would think you'd want the SRS, as the recipient of the media, to=20 >>>decide whether it wants mixed or unmixed media. And that the SRC must=20 >>>support both, and must comply with the SRS's request. And that=20 >>>implies that you must have a mechanism for the SRC to tell the SRC=20 >>>whether it wants mixed or unmixed media. >> >> You are going to *require* that the SRC be able to do mixing??? >> >>> An SRS may receive from many SRCs. What I suggest above allows=20 >>>policy to be implemented in one place (the SRS), and forces all SRCs=20 >>>to comply with it. >> >> On the contrary, ISTM that the SRS is a *utility*, and one that=20 >>probably has considerable resources. It is providing a service to a=20 >>wide range of clients that may vary widely in their capabilities. >> It makes much or sense to me that life is made as simple and flexible=20 >>as possible for the SRC. >> >> Leon indicated that some preliminary implementations prefer to=20 >>receive the streams unmixed. That is also perhaps easier for the SRC,=20 >>at the expense of requiring more bandwidth. Certainly its easier for a "p= hone" >> that might have no mixing capability at all. OTOH there may be=20 >>devices that are very bandwidth limited that would prefer to mix first=20 >>to conserve the bandwidth. And there may be some devices, such as a=20 >>conference focus, for which mixing may be the most convenient way. And=20 >>of course there could be an SRC that is a *participant* in a=20 >>conference, that has no choice but to accept mixed media from the=20 >>focus, and so must pass it along unmixed to the SRS. >> >> Thanks, >> Paul >> >>> Michael Smith >>> Chief Technologist >>> Ph: 606.877.2788 | Mobile: 606.231.0243 >>> >>> DSS Corporation / Equature >>> 18311 W. Ten Mile Road, Suite 200 >>> Southfield, MI - 48075 >>> Tel: 1-888.305.3428 >>> Fax: 1-248.569.6567 >>> www.dss-corp.com >>> www.dispatchimprovement.com >>> >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>> Behalf Of Leon Portman >>> Sent: Thursday, July 26, 2012 4:59 PM >>> To: Paul Kyzivat >>> Cc: siprec@ietf.org >>> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >>> >>> Paul Hi >>> >>> Generic comment: current implementations of SRS support to be=20 >>>configured either store unmixed media separately or mixed them on=20 >>>SRS side in order to save storage. >>> On protocol side: we can define a negotiation of mixing like this:=20 >>>If SRC supports sending both mixed and unmixed medias, it can offer=20 >>>both in SDP as multiple m-lines and SRS can accept the preferred option. >>> Of if it is specific policy on SRC side, SRS still can have option=20 >>>to mix if SRC always sends unmixed. >>> >>> What do you think? >>> >>> >>> Leon >>> >>> On Jul 26, 2012, at 11:53 PM, Paul Kyzivat >>>wrote: >>> >>>> One small comment on this: >>>> >>>> Section 3.2.4: >>>> >>>> When recording this media the two streams may be >>>> mixed at the SRC before being transmitted to the SRS or it may=20 >>>>be a >>>> requirement of the recording server that the media streams are not >>>> mixed and are sent to the SRS as two separate streams. >>>> >>>> Do we really want to say that the SRS can decide that it must have=20 >>>>unmixed media??? >>>> >>>> I don't think so. IMO this should be solely at the discretion of=20 >>>>the SRC. >>>> >>>> If it was up to the SRS, how would it indicate this to the SRC? >>>> _______________________________________________ >>>> 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 DAVE.HIGTON@nice.com Fri Jul 27 07:15: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 E7CA721F861D for ; Fri, 27 Jul 2012 07:15:41 -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 QcEeomngIUKZ for ; Fri, 27 Jul 2012 07:15:40 -0700 (PDT) Received: from soumd01.eu.nice.com (UKEmail.nice.com [195.166.55.162]) by ietfa.amsl.com (Postfix) with ESMTP id 65C3D21F8616 for ; Fri, 27 Jul 2012 07:15:40 -0700 (PDT) Received: from SOUCAS01.eu.nice.com ([10.1.1.9]) by soumd01.eu.nice.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jul 2012 15:15:37 +0100 Received: from SOUEXC01.eu.nice.com ([fe80::ec6d:6017:186e:e8f8]) by SOUCAS01.eu.nice.com ([::1]) with mapi; Fri, 27 Jul 2012 15:15:36 +0100 From: Dave Higton To: "siprec@ietf.org" Date: Fri, 27 Jul 2012 15:15:35 +0100 Thread-Topic: [siprec] Comments on draft-ietf-siprec-architecture-05 Thread-Index: AQHNa3Czt4ZtpSjdMEe219lQXs2A+5c8TyqA//++Z2CAAFbNAP//xgFggABkW4CAAEKLgIAASdxQgAARLIA= Message-ID: <9B0B6FB9606F4D4AB133C5E9A203B6940559DF494B@SOUEXC01.eu.nice.com> References: <5011E4ED.1080101@alum.mit.edu> <05D56509F27CCE4DAF8136C02386880D686CBD5A@exc01.dss.lan> In-Reply-To: <05D56509F27CCE4DAF8136C02386880D686CBD5A@exc01.dss.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jul 2012 14:15:37.0827 (UTC) FILETIME=[4BA23B30:01CD6C02] Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 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, 27 Jul 2012 14:15:42 -0000 I am accustomed to thinking that the choice to record mixed or unmixed medi= a is made at time of placing a contract to purchase recording equipment. T= hat places no requirement to specify at recording time. Is there, therefore, a case for saying that SIPREC does not need to support= such a choice? Dave -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Michael Smith Sent: 27 July 2012 14:28 To: siprec@ietf.org Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 So Ram proposes: We can have an SRC that does one or more of the following: 1)An SRC MAY support sending unmixed media only 2) An SRC supports sending mixed media only (the case of conference whe= re SRC is a participant) 3) An SRC supports sending mixed or unmixed media or both I'm curious - do others agree with that position? IMHO, the SRC conference participant case is a non-issue. If an SRC is a pa= rticipant in a Bridge, the "mixed" media coming from the Bridge is a single= stream from its point of view, and an SRS that wanted unmixed media would = only get whatever streams the SRC had.=20 Now, I would like to see the possibility of the SRS dictating (or at least = indicating a desire for) mixed or unmixed media, but if the majority disagr= ee, I can live with that. I do want to bring this up with the NENA NG9-1-1 recording test committee I= chair. Nine recording companies participate, and I'd like to see if that g= roup thinks we should impose additional requirements for an SRC/SRS used in= an NG9-1-1 environment. I don't personally think that Public Safety needs = are different than private sector needs on this issue, but it's a good disc= ussion to have now. If there were no mechanism for the SRS to make its mixe= d/unmixed desire known, we'd have a problem to solve. Perhaps this group co= uld define such a mechanism without requiring that it be used? Thanks, Michael Smith Chief Technologist Ph: 606.877.2788 | Mobile: 606.231.0243=20 DSS Corporation / Equature 18311=A0=A0 W. Ten Mile Road, Suite 200 Southfield, MI - 48075 Tel: 1-888.305.3428 Fax: 1-248.569.6567 www.dss-corp.com www.dispatchimprovement.com -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Ram Mohan R (rmohanr) Sent: Friday, July 27, 2012 12:45 AM To: Paul Kyzivat; siprec@ietf.org Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > On 27/07/12 6:16 AM, "Paul Kyzivat" wrote: >On 7/26/12 7:08 PM, Michael Smith wrote: >> Hmmm... What's important is that the SRC supports unmixed streams. If=20 >>it does, the server could mix them, and policy is enforced at that=20 >>point. The drawback to that is that you consume twice the bandwidth=20 >>per CS, even if your policy is to store mixed streams. >> >> Good point about a phone, but they do already mix the two parties=20 >>voices. Mixing is simple, and not processing-intensive, so levying=20 >>that requirement on an SRC isn't onerous, IMHO. >> >> I'd be ok if an SRC didn't support mixing media, and the SRS mixed it. >>But I think it's a problem if an SRC mixes media and policy dictates=20 >>that unmixed media be stored - there's no way to un-mix it. > >So what about an SRC connected to a focus of a conference with many=20 >participants. The SRC is only receiving a mixed stream from the focus,=20 >which includes all participants except itself. It can know who all the=20 >participants are (from the conference event package), but it can't pass=20 >them on unmixed. > >> I think requirements might be crafted that an SRS MUST support=20 >>receiving both mixed and unmixed media, and an SRC MUST support=20 >>sending unmixed media, and MAY support sending mixed media. You'd=20 >>still need some mechanism for negotiating mixed/unmixed. > >I'm going to stand by my prior opinion for now. > >As a customer I think you can *prefer* that things work this way. If=20 >you have buying control over the SRC you can specify that. But I don't=20 >think it makes sense to exclude SRCs that work otherwise. I also agree with Paul. We can have an SRC that does one or more of the following: 1)An SRC MAY support sending unmixed media only 2) An SRC supports sending mixed media only (the case of conference where S= RC is a participant) 3) An SRC supports sending mixed or unmixed media or both So its better not to restrict and there by exclude some SRCs. Ram > > Thanks, > Paul > >> Michael Smith >> Chief Technologist >> Ph: 606.877.2788 | Mobile: 606.231.0243 >> >> DSS Corporation / Equature >> 18311 W. Ten Mile Road, Suite 200 >> Southfield, MI - 48075 >> Tel: 1-888.305.3428 >> Fax: 1-248.569.6567 >> www.dss-corp.com >> www.dispatchimprovement.com >> >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>Behalf Of Paul Kyzivat >> Sent: Thursday, July 26, 2012 6:15 PM >> To: siprec@ietf.org >> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >> >> On 7/26/12 5:11 PM, Michael Smith wrote: >>> I would think you'd want the SRS, as the recipient of the media, to=20 >>>decide whether it wants mixed or unmixed media. And that the SRC must=20 >>>support both, and must comply with the SRS's request. And that=20 >>>implies that you must have a mechanism for the SRC to tell the SRC=20 >>>whether it wants mixed or unmixed media. >> >> You are going to *require* that the SRC be able to do mixing??? >> >>> An SRS may receive from many SRCs. What I suggest above allows=20 >>>policy to be implemented in one place (the SRS), and forces all SRCs=20 >>>to comply with it. >> >> On the contrary, ISTM that the SRS is a *utility*, and one that=20 >>probably has considerable resources. It is providing a service to a=20 >>wide range of clients that may vary widely in their capabilities. >> It makes much or sense to me that life is made as simple and flexible=20 >>as possible for the SRC. >> >> Leon indicated that some preliminary implementations prefer to=20 >>receive the streams unmixed. That is also perhaps easier for the SRC,=20 >>at the expense of requiring more bandwidth. Certainly its easier for a "p= hone" >> that might have no mixing capability at all. OTOH there may be=20 >>devices that are very bandwidth limited that would prefer to mix first=20 >>to conserve the bandwidth. And there may be some devices, such as a=20 >>conference focus, for which mixing may be the most convenient way. And=20 >>of course there could be an SRC that is a *participant* in a=20 >>conference, that has no choice but to accept mixed media from the=20 >>focus, and so must pass it along unmixed to the SRS. >> >> Thanks, >> Paul >> >>> Michael Smith >>> Chief Technologist >>> Ph: 606.877.2788 | Mobile: 606.231.0243 >>> >>> DSS Corporation / Equature >>> 18311 W. Ten Mile Road, Suite 200 >>> Southfield, MI - 48075 >>> Tel: 1-888.305.3428 >>> Fax: 1-248.569.6567 >>> www.dss-corp.com >>> www.dispatchimprovement.com >>> >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>> Behalf Of Leon Portman >>> Sent: Thursday, July 26, 2012 4:59 PM >>> To: Paul Kyzivat >>> Cc: siprec@ietf.org >>> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >>> >>> Paul Hi >>> >>> Generic comment: current implementations of SRS support to be=20 >>>configured either store unmixed media separately or mixed them on=20 >>>SRS side in order to save storage. >>> On protocol side: we can define a negotiation of mixing like this:=20 >>>If SRC supports sending both mixed and unmixed medias, it can offer=20 >>>both in SDP as multiple m-lines and SRS can accept the preferred option. >>> Of if it is specific policy on SRC side, SRS still can have option=20 >>>to mix if SRC always sends unmixed. >>> >>> What do you think? >>> >>> >>> Leon >>> >>> On Jul 26, 2012, at 11:53 PM, Paul Kyzivat >>>wrote: >>> >>>> One small comment on this: >>>> >>>> Section 3.2.4: >>>> >>>> When recording this media the two streams may be >>>> mixed at the SRC before being transmitted to the SRS or it may=20 >>>>be a >>>> requirement of the recording server that the media streams are not >>>> mixed and are sent to the SRS as two separate streams. >>>> >>>> Do we really want to say that the SRS can decide that it must have=20 >>>>unmixed media??? >>>> >>>> I don't think so. IMO this should be solely at the discretion of=20 >>>>the SRC. >>>> >>>> If it was up to the SRS, how would it indicate this to the SRC? >>>> _______________________________________________ >>>> 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 prvs=1555156da9=MSmith@dss-corp.com Fri Jul 27 07:27: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 1801B21F877E for ; Fri, 27 Jul 2012 07:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 jpTjGBMkaG7q for ; Fri, 27 Jul 2012 07:27:09 -0700 (PDT) Received: from spam.dss-corp.com (spam.dss-corp.com [67.214.118.46]) by ietfa.amsl.com (Postfix) with ESMTP id 9979921F877C for ; Fri, 27 Jul 2012 07:27:08 -0700 (PDT) Received: from spam.dss-corp.com (127.0.0.1) by spam.dss-corp.com (MlfMTA v3.2r9) id h2ajem0171s9 for ; Fri, 27 Jul 2012 10:34:19 -0400 (envelope-from ) Received: from exc.dss-corp.com ([192.168.1.5]) by spam.dss-corp.com (SonicWALL 7.2.4.3929) with ESMTP; Fri, 27 Jul 2012 10:34:19 -0400 Received: from EXC01.dss.lan ([fe80::109b:ad4:1a47:2813]) by exc01.dss.lan ([fe80::109b:ad4:1a47:2813%13]) with mapi; Fri, 27 Jul 2012 10:27:06 -0400 From: Michael Smith To: "siprec@ietf.org" Thread-Topic: [siprec] Comments on draft-ietf-siprec-architecture-05 Thread-Index: AQHNa3Czt4ZtpSjdMEe219lQXs2A+5c8TyqA//++Z2CAAFbNAP//xgFggABkW4CAAEKLgIAASdxQgAARLICAAAGlgA== Date: Fri, 27 Jul 2012 14:26:47 +0000 Message-ID: <05D56509F27CCE4DAF8136C02386880D686CC27E@exc01.dss.lan> References: <5011E4ED.1080101@alum.mit.edu> <05D56509F27CCE4DAF8136C02386880D686CBD5A@exc01.dss.lan> <9B0B6FB9606F4D4AB133C5E9A203B6940559DF494B@SOUEXC01.eu.nice.com> In-Reply-To: <9B0B6FB9606F4D4AB133C5E9A203B6940559DF494B@SOUEXC01.eu.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mlf-Version: 7.2.4.3929 X-Mlf-UniqueId: o201207271434190085682 Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 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, 27 Jul 2012 14:27:10 -0000 Yeah, I think Paul made the case that a customer can buy an SRC that suppor= ts sending mixed, unmixed or both. But without some requirement, we don't k= now what vendors will produce, and you can only buy what's available. I'm ok with the proposal Paul and Ram made, as long as we're all ok with th= e possibility that SRC vendors might offer only mixed, or conversely, only = unmixed. Either could happen, but I suspect the "mixed only" option would b= e what we'd end up with - and that's the problem. The server doesn't even h= ave a choice if that's all the SRC offers. It can only record mixed media. BTW, I looked at the current NENA 08-003 draft. It looks like we dropped th= e sentence we initially had about recording unmixed media, perhaps for the = same reasons Paul and Ram have presented. I still would like to have some mechanism for the SRS to make its desire fo= r mixed or unmixed known, and then say that it MAY be used, and the SRC MAY= comply with the request. I think that's better than nothing. Michael Smith Chief Technologist Ph: 606.877.2788 | Mobile: 606.231.0243=20 DSS Corporation / Equature 18311=A0=A0 W. Ten Mile Road, Suite 200 Southfield, MI - 48075 Tel: 1-888.305.3428 Fax: 1-248.569.6567 www.dss-corp.com www.dispatchimprovement.com -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Dave Higton Sent: Friday, July 27, 2012 10:16 AM To: siprec@ietf.org Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 I am accustomed to thinking that the choice to record mixed or unmixed medi= a is made at time of placing a contract to purchase recording equipment. T= hat places no requirement to specify at recording time. Is there, therefore, a case for saying that SIPREC does not need to support= such a choice? Dave -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Michael Smith Sent: 27 July 2012 14:28 To: siprec@ietf.org Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 So Ram proposes: We can have an SRC that does one or more of the following: 1)An SRC MAY support sending unmixed media only 2) An SRC supports sending mixed media only (the case of conference whe= re SRC is a participant) 3) An SRC supports sending mixed or unmixed media or both I'm curious - do others agree with that position? IMHO, the SRC conference participant case is a non-issue. If an SRC is a pa= rticipant in a Bridge, the "mixed" media coming from the Bridge is a single= stream from its point of view, and an SRS that wanted unmixed media would = only get whatever streams the SRC had.=20 Now, I would like to see the possibility of the SRS dictating (or at least = indicating a desire for) mixed or unmixed media, but if the majority disagr= ee, I can live with that. I do want to bring this up with the NENA NG9-1-1 recording test committee I= chair. Nine recording companies participate, and I'd like to see if that g= roup thinks we should impose additional requirements for an SRC/SRS used in= an NG9-1-1 environment. I don't personally think that Public Safety needs = are different than private sector needs on this issue, but it's a good disc= ussion to have now. If there were no mechanism for the SRS to make its mixe= d/unmixed desire known, we'd have a problem to solve. Perhaps this group co= uld define such a mechanism without requiring that it be used? Thanks, Michael Smith Chief Technologist Ph: 606.877.2788 | Mobile: 606.231.0243=20 DSS Corporation / Equature 18311=A0=A0 W. Ten Mile Road, Suite 200 Southfield, MI - 48075 Tel: 1-888.305.3428 Fax: 1-248.569.6567 www.dss-corp.com www.dispatchimprovement.com -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Ram Mohan R (rmohanr) Sent: Friday, July 27, 2012 12:45 AM To: Paul Kyzivat; siprec@ietf.org Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > On 27/07/12 6:16 AM, "Paul Kyzivat" wrote: >On 7/26/12 7:08 PM, Michael Smith wrote: >> Hmmm... What's important is that the SRC supports unmixed streams. If=20 >>it does, the server could mix them, and policy is enforced at that=20 >>point. The drawback to that is that you consume twice the bandwidth=20 >>per CS, even if your policy is to store mixed streams. >> >> Good point about a phone, but they do already mix the two parties=20 >>voices. Mixing is simple, and not processing-intensive, so levying=20 >>that requirement on an SRC isn't onerous, IMHO. >> >> I'd be ok if an SRC didn't support mixing media, and the SRS mixed it. >>But I think it's a problem if an SRC mixes media and policy dictates=20 >>that unmixed media be stored - there's no way to un-mix it. > >So what about an SRC connected to a focus of a conference with many=20 >participants. The SRC is only receiving a mixed stream from the focus,=20 >which includes all participants except itself. It can know who all the=20 >participants are (from the conference event package), but it can't pass=20 >them on unmixed. > >> I think requirements might be crafted that an SRS MUST support=20 >>receiving both mixed and unmixed media, and an SRC MUST support=20 >>sending unmixed media, and MAY support sending mixed media. You'd=20 >>still need some mechanism for negotiating mixed/unmixed. > >I'm going to stand by my prior opinion for now. > >As a customer I think you can *prefer* that things work this way. If=20 >you have buying control over the SRC you can specify that. But I don't=20 >think it makes sense to exclude SRCs that work otherwise. I also agree with Paul. We can have an SRC that does one or more of the following: 1)An SRC MAY support sending unmixed media only 2) An SRC supports sending mixed media only (the case of conference where S= RC is a participant) 3) An SRC supports sending mixed or unmixed media or both So its better not to restrict and there by exclude some SRCs. Ram > > Thanks, > Paul > >> Michael Smith >> Chief Technologist >> Ph: 606.877.2788 | Mobile: 606.231.0243 >> >> DSS Corporation / Equature >> 18311 W. Ten Mile Road, Suite 200 >> Southfield, MI - 48075 >> Tel: 1-888.305.3428 >> Fax: 1-248.569.6567 >> www.dss-corp.com >> www.dispatchimprovement.com >> >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>Behalf Of Paul Kyzivat >> Sent: Thursday, July 26, 2012 6:15 PM >> To: siprec@ietf.org >> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >> >> On 7/26/12 5:11 PM, Michael Smith wrote: >>> I would think you'd want the SRS, as the recipient of the media, to=20 >>>decide whether it wants mixed or unmixed media. And that the SRC must=20 >>>support both, and must comply with the SRS's request. And that=20 >>>implies that you must have a mechanism for the SRC to tell the SRC=20 >>>whether it wants mixed or unmixed media. >> >> You are going to *require* that the SRC be able to do mixing??? >> >>> An SRS may receive from many SRCs. What I suggest above allows=20 >>>policy to be implemented in one place (the SRS), and forces all SRCs=20 >>>to comply with it. >> >> On the contrary, ISTM that the SRS is a *utility*, and one that=20 >>probably has considerable resources. It is providing a service to a=20 >>wide range of clients that may vary widely in their capabilities. >> It makes much or sense to me that life is made as simple and flexible=20 >>as possible for the SRC. >> >> Leon indicated that some preliminary implementations prefer to=20 >>receive the streams unmixed. That is also perhaps easier for the SRC,=20 >>at the expense of requiring more bandwidth. Certainly its easier for a "p= hone" >> that might have no mixing capability at all. OTOH there may be=20 >>devices that are very bandwidth limited that would prefer to mix first=20 >>to conserve the bandwidth. And there may be some devices, such as a=20 >>conference focus, for which mixing may be the most convenient way. And=20 >>of course there could be an SRC that is a *participant* in a=20 >>conference, that has no choice but to accept mixed media from the=20 >>focus, and so must pass it along unmixed to the SRS. >> >> Thanks, >> Paul >> >>> Michael Smith >>> Chief Technologist >>> Ph: 606.877.2788 | Mobile: 606.231.0243 >>> >>> DSS Corporation / Equature >>> 18311 W. Ten Mile Road, Suite 200 >>> Southfield, MI - 48075 >>> Tel: 1-888.305.3428 >>> Fax: 1-248.569.6567 >>> www.dss-corp.com >>> www.dispatchimprovement.com >>> >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>> Behalf Of Leon Portman >>> Sent: Thursday, July 26, 2012 4:59 PM >>> To: Paul Kyzivat >>> Cc: siprec@ietf.org >>> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >>> >>> Paul Hi >>> >>> Generic comment: current implementations of SRS support to be=20 >>>configured either store unmixed media separately or mixed them on=20 >>>SRS side in order to save storage. >>> On protocol side: we can define a negotiation of mixing like this:=20 >>>If SRC supports sending both mixed and unmixed medias, it can offer=20 >>>both in SDP as multiple m-lines and SRS can accept the preferred option. >>> Of if it is specific policy on SRC side, SRS still can have option=20 >>>to mix if SRC always sends unmixed. >>> >>> What do you think? >>> >>> >>> Leon >>> >>> On Jul 26, 2012, at 11:53 PM, Paul Kyzivat >>>wrote: >>> >>>> One small comment on this: >>>> >>>> Section 3.2.4: >>>> >>>> When recording this media the two streams may be >>>> mixed at the SRC before being transmitted to the SRS or it may=20 >>>>be a >>>> requirement of the recording server that the media streams are not >>>> mixed and are sent to the SRS as two separate streams. >>>> >>>> Do we really want to say that the SRS can decide that it must have=20 >>>>unmixed media??? >>>> >>>> I don't think so. IMO this should be solely at the discretion of=20 >>>>the SRC. >>>> >>>> If it was up to the SRS, how would it indicate this to the SRC? >>>> _______________________________________________ >>>> 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 leon.portman@gmail.com Fri Jul 27 07:32: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 00A2121F8790 for ; Fri, 27 Jul 2012 07:32:07 -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 7NCIRi257xEH for ; Fri, 27 Jul 2012 07:32:05 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4760921F8781 for ; Fri, 27 Jul 2012 07:32:05 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1924457wgb.13 for ; Fri, 27 Jul 2012 07:32:04 -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=LBSYbRSfqVvjvcuBco2W95kYR1FVYg+LSmo9gsS2cwU=; b=EDvnBZf1fPIneJ3EXZUUVRPb3NMZx1VuTzahrsL84CKjYYxU8LXMQUap/TjBW4mcsB WH/rQXIae7AVvJUpqDc3SZfMjtBzBFcCQs9hpPMp2hA+azBQXvN2XA9Q3TZ39Qq53PC1 BP/WcGCJz8MFecoTl8sGTV9rJxc5uuqJe5xHBQdpzIu5iyhm8KrKzyywXRlA7WD7eoGn KkpfvPFNqj3SWZCjvt6grU6YmtrVtl5wUUYZdz3F0OLmP+G44kGUH3nxkfQDhzGq2g8k 0q3eZf8TFG2sk65ubeszY5UVwAzcGeWwvQkXaxp9V9mCmf9FzUVwPmFhDRrIvKIqEz4o 15bQ== Received: by 10.180.78.4 with SMTP id x4mr22667756wiw.19.1343399524215; Fri, 27 Jul 2012 07:32:04 -0700 (PDT) Received: from [192.168.2.105] (46-116-44-105.bb.netvision.net.il. [46.116.44.105]) by mx.google.com with ESMTPS id ep14sm4824586wid.0.2012.07.27.07.32.02 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Jul 2012 07:32:03 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Leon Portman In-Reply-To: <05D56509F27CCE4DAF8136C02386880D686CC27E@exc01.dss.lan> Date: Fri, 27 Jul 2012 17:32:01 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <364837A9-EC2F-4BE3-9DD0-13A376496B60@gmail.com> References: <5011E4ED.1080101@alum.mit.edu> <05D56509F27CCE4DAF8136C02386880D686CBD5A@exc01.dss.lan> <9B0B6FB9606F4D4AB133C5E9A203B6940559DF494B@SOUEXC01.eu.nice.com> <05D56509F27CCE4DAF8136C02386880D686CC27E@exc01.dss.lan> To: Michael Smith X-Mailer: Apple Mail (2.1485) Cc: "siprec@ietf.org" Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 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, 27 Jul 2012 14:32:07 -0000 I agree with Michael. It is will be useful for SRS to indicate when = unmixed audio is preferable. One of the use cases is if some specific = calls are analyzed in real time for fraud, and only these calls should = be unmixed for better accuracy Leon Leon On Jul 27, 2012, at 5:26 PM, Michael Smith wrote: > Yeah, I think Paul made the case that a customer can buy an SRC that = supports sending mixed, unmixed or both. But without some requirement, = we don't know what vendors will produce, and you can only buy what's = available. >=20 > I'm ok with the proposal Paul and Ram made, as long as we're all ok = with the possibility that SRC vendors might offer only mixed, or = conversely, only unmixed. Either could happen, but I suspect the "mixed = only" option would be what we'd end up with - and that's the problem. = The server doesn't even have a choice if that's all the SRC offers. It = can only record mixed media. >=20 > BTW, I looked at the current NENA 08-003 draft. It looks like we = dropped the sentence we initially had about recording unmixed media, = perhaps for the same reasons Paul and Ram have presented. >=20 > I still would like to have some mechanism for the SRS to make its = desire for mixed or unmixed known, and then say that it MAY be used, and = the SRC MAY comply with the request. I think that's better than nothing. >=20 > Michael Smith > Chief Technologist > Ph: 606.877.2788 | Mobile: 606.231.0243=20 >=20 > DSS Corporation / Equature > 18311 W. Ten Mile Road, Suite 200 > Southfield, MI - 48075 > Tel: 1-888.305.3428 > Fax: 1-248.569.6567 > www.dss-corp.com > www.dispatchimprovement.com >=20 >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On = Behalf Of Dave Higton > Sent: Friday, July 27, 2012 10:16 AM > To: siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >=20 > I am accustomed to thinking that the choice to record mixed or unmixed = media is made at time of placing a contract to purchase recording = equipment. That places no requirement to specify at recording time. >=20 > Is there, therefore, a case for saying that SIPREC does not need to = support such a choice? >=20 > Dave >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On = Behalf Of Michael Smith > Sent: 27 July 2012 14:28 > To: siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >=20 > So Ram proposes: > We can have an SRC that does one or more of the following: > 1)An SRC MAY support sending unmixed media only > 2) An SRC supports sending mixed media only (the case of conference = where SRC is a participant) > 3) An SRC supports sending mixed or unmixed media or both >=20 > I'm curious - do others agree with that position? >=20 > IMHO, the SRC conference participant case is a non-issue. If an SRC is = a participant in a Bridge, the "mixed" media coming from the Bridge is a = single stream from its point of view, and an SRS that wanted unmixed = media would only get whatever streams the SRC had.=20 >=20 > Now, I would like to see the possibility of the SRS dictating (or at = least indicating a desire for) mixed or unmixed media, but if the = majority disagree, I can live with that. >=20 > I do want to bring this up with the NENA NG9-1-1 recording test = committee I chair. Nine recording companies participate, and I'd like to = see if that group thinks we should impose additional requirements for an = SRC/SRS used in an NG9-1-1 environment. I don't personally think that = Public Safety needs are different than private sector needs on this = issue, but it's a good discussion to have now. If there were no = mechanism for the SRS to make its mixed/unmixed desire known, we'd have = a problem to solve. Perhaps this group could define such a mechanism = without requiring that it be used? >=20 >=20 > Thanks, >=20 > Michael Smith > Chief Technologist > Ph: 606.877.2788 | Mobile: 606.231.0243=20 >=20 > DSS Corporation / Equature > 18311 W. Ten Mile Road, Suite 200 > Southfield, MI - 48075 > Tel: 1-888.305.3428 > Fax: 1-248.569.6567 > www.dss-corp.com > www.dispatchimprovement.com >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On = Behalf Of Ram Mohan R (rmohanr) > Sent: Friday, July 27, 2012 12:45 AM > To: Paul Kyzivat; siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >=20 >> On 27/07/12 6:16 AM, "Paul Kyzivat" wrote: >=20 >> On 7/26/12 7:08 PM, Michael Smith wrote: >>> Hmmm... What's important is that the SRC supports unmixed streams. = If=20 >>> it does, the server could mix them, and policy is enforced at that=20= >>> point. The drawback to that is that you consume twice the bandwidth=20= >>> per CS, even if your policy is to store mixed streams. >>>=20 >>> Good point about a phone, but they do already mix the two parties=20 >>> voices. Mixing is simple, and not processing-intensive, so levying=20= >>> that requirement on an SRC isn't onerous, IMHO. >>>=20 >>> I'd be ok if an SRC didn't support mixing media, and the SRS mixed = it. >>> But I think it's a problem if an SRC mixes media and policy dictates=20= >>> that unmixed media be stored - there's no way to un-mix it. >>=20 >> So what about an SRC connected to a focus of a conference with many=20= >> participants. The SRC is only receiving a mixed stream from the = focus,=20 >> which includes all participants except itself. It can know who all = the=20 >> participants are (from the conference event package), but it can't = pass=20 >> them on unmixed. >>=20 >>> I think requirements might be crafted that an SRS MUST support=20 >>> receiving both mixed and unmixed media, and an SRC MUST support=20 >>> sending unmixed media, and MAY support sending mixed media. You'd=20 >>> still need some mechanism for negotiating mixed/unmixed. >>=20 >> I'm going to stand by my prior opinion for now. >>=20 >> As a customer I think you can *prefer* that things work this way. If=20= >> you have buying control over the SRC you can specify that. But I = don't=20 >> think it makes sense to exclude SRCs that work otherwise. >=20 >=20 > I also agree with Paul. We can have an SRC that does one or more of = the > following: > 1)An SRC MAY support sending unmixed media only > 2) An SRC supports sending mixed media only (the case of conference = where SRC is a participant) > 3) An SRC supports sending mixed or unmixed media or both >=20 > So its better not to restrict and there by exclude some SRCs. >=20 > Ram >=20 >>=20 >> Thanks, >> Paul >>=20 >>> Michael Smith >>> Chief Technologist >>> Ph: 606.877.2788 | Mobile: 606.231.0243 >>>=20 >>> DSS Corporation / Equature >>> 18311 W. Ten Mile Road, Suite 200 >>> Southfield, MI - 48075 >>> Tel: 1-888.305.3428 >>> Fax: 1-248.569.6567 >>> www.dss-corp.com >>> www.dispatchimprovement.com >>>=20 >>>=20 >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>> Behalf Of Paul Kyzivat >>> Sent: Thursday, July 26, 2012 6:15 PM >>> To: siprec@ietf.org >>> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >>>=20 >>> On 7/26/12 5:11 PM, Michael Smith wrote: >>>> I would think you'd want the SRS, as the recipient of the media, to=20= >>>> decide whether it wants mixed or unmixed media. And that the SRC = must=20 >>>> support both, and must comply with the SRS's request. And that=20 >>>> implies that you must have a mechanism for the SRC to tell the SRC=20= >>>> whether it wants mixed or unmixed media. >>>=20 >>> You are going to *require* that the SRC be able to do mixing??? >>>=20 >>>> An SRS may receive from many SRCs. What I suggest above allows=20 >>>> policy to be implemented in one place (the SRS), and forces all = SRCs=20 >>>> to comply with it. >>>=20 >>> On the contrary, ISTM that the SRS is a *utility*, and one that=20 >>> probably has considerable resources. It is providing a service to a=20= >>> wide range of clients that may vary widely in their capabilities. >>> It makes much or sense to me that life is made as simple and = flexible=20 >>> as possible for the SRC. >>>=20 >>> Leon indicated that some preliminary implementations prefer to=20 >>> receive the streams unmixed. That is also perhaps easier for the = SRC,=20 >>> at the expense of requiring more bandwidth. Certainly its easier for = a "phone" >>> that might have no mixing capability at all. OTOH there may be=20 >>> devices that are very bandwidth limited that would prefer to mix = first=20 >>> to conserve the bandwidth. And there may be some devices, such as a=20= >>> conference focus, for which mixing may be the most convenient way. = And=20 >>> of course there could be an SRC that is a *participant* in a=20 >>> conference, that has no choice but to accept mixed media from the=20 >>> focus, and so must pass it along unmixed to the SRS. >>>=20 >>> Thanks, >>> Paul >>>=20 >>>> Michael Smith >>>> Chief Technologist >>>> Ph: 606.877.2788 | Mobile: 606.231.0243 >>>>=20 >>>> DSS Corporation / Equature >>>> 18311 W. Ten Mile Road, Suite 200 >>>> Southfield, MI - 48075 >>>> Tel: 1-888.305.3428 >>>> Fax: 1-248.569.6567 >>>> www.dss-corp.com >>>> www.dispatchimprovement.com >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20= >>>> Behalf Of Leon Portman >>>> Sent: Thursday, July 26, 2012 4:59 PM >>>> To: Paul Kyzivat >>>> Cc: siprec@ietf.org >>>> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >>>>=20 >>>> Paul Hi >>>>=20 >>>> Generic comment: current implementations of SRS support to be=20 >>>> configured either store unmixed media separately or mixed them on=20= >>>> SRS side in order to save storage. >>>> On protocol side: we can define a negotiation of mixing like this:=20= >>>> If SRC supports sending both mixed and unmixed medias, it can offer=20= >>>> both in SDP as multiple m-lines and SRS can accept the preferred = option. >>>> Of if it is specific policy on SRC side, SRS still can have option=20= >>>> to mix if SRC always sends unmixed. >>>>=20 >>>> What do you think? >>>>=20 >>>>=20 >>>> Leon >>>>=20 >>>> On Jul 26, 2012, at 11:53 PM, Paul Kyzivat >>>> wrote: >>>>=20 >>>>> One small comment on this: >>>>>=20 >>>>> Section 3.2.4: >>>>>=20 >>>>> When recording this media the two streams may be >>>>> mixed at the SRC before being transmitted to the SRS or it may=20= >>>>> be a >>>>> requirement of the recording server that the media streams are = not >>>>> mixed and are sent to the SRS as two separate streams. >>>>>=20 >>>>> Do we really want to say that the SRS can decide that it must have=20= >>>>> unmixed media??? >>>>>=20 >>>>> I don't think so. IMO this should be solely at the discretion of=20= >>>>> the SRC. >>>>>=20 >>>>> If it was up to the SRS, how would it indicate this to the SRC? >>>>> _______________________________________________ >>>>> 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 >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>>>=20 >>>=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 >>>=20 >>=20 >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >>=20 >=20 >=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 pkyzivat@alum.mit.edu Fri Jul 27 07:44: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 D593421F8787 for ; Fri, 27 Jul 2012 07:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=0.296, 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 qn1Nc4Kqi+5t for ; Fri, 27 Jul 2012 07:44:15 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5D721F870B for ; Fri, 27 Jul 2012 07:44:15 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta15.westchester.pa.mail.comcast.net with comcast id fSeB1j0081vXlb85FSkRCV; Fri, 27 Jul 2012 14:44:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id fSkL1j00b3ZTu2S3dSkLB1; Fri, 27 Jul 2012 14:44:20 +0000 Message-ID: <5012A93D.5020006@alum.mit.edu> Date: Fri, 27 Jul 2012 10:44:13 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <5011E4ED.1080101@alum.mit.edu> <05D56509F27CCE4DAF8136C02386880D686CBD5A@exc01.dss.lan> <9B0B6FB9606F4D4AB133C5E9A203B6940559DF494B@SOUEXC01.eu.nice.com> <05D56509F27CCE4DAF8136C02386880D686CC27E@exc01.dss.lan> In-Reply-To: <05D56509F27CCE4DAF8136C02386880D686CC27E@exc01.dss.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 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, 27 Jul 2012 14:44:17 -0000 On 7/27/12 10:26 AM, Michael Smith wrote: > Yeah, I think Paul made the case that a customer can buy an SRC that supports sending mixed, unmixed or both. But without some requirement, we don't know what vendors will produce, and you can only buy what's available. > > I'm ok with the proposal Paul and Ram made, as long as we're all ok with the possibility that SRC vendors might offer only mixed, or conversely, only unmixed. Either could happen, but I suspect the "mixed only" option would be what we'd end up with - and that's the problem. The server doesn't even have a choice if that's all the SRC offers. It can only record mixed media. > > BTW, I looked at the current NENA 08-003 draft. It looks like we dropped the sentence we initially had about recording unmixed media, perhaps for the same reasons Paul and Ram have presented. > > I still would like to have some mechanism for the SRS to make its desire for mixed or unmixed known, and then say that it MAY be used, and the SRC MAY comply with the request. I think that's better than nothing. I am agreeable with having some discussion of how the SRS can express some preferences to the SRC. It doesn't seem to fit well within the communication framework we have defined so far, so it might require some significant changes. One problem is that currently its possible for the SRC to send an INVITE to initiate an RS, with an SDP offer and metadata describing what it wants recorded initially. The construction of that offer and the metadata already embodies a policy decision about how to do the recording - whether mixed or unmixed. And at that time there has been *no* opportunity for the SRS to indicate its preferences. And I've been led to believe its important that things work this way so that a recording can be established rapidly. Thanks, Paul > Michael Smith > Chief Technologist > Ph: 606.877.2788 | Mobile: 606.231.0243 > > DSS Corporation / Equature > 18311 W. Ten Mile Road, Suite 200 > Southfield, MI - 48075 > Tel: 1-888.305.3428 > Fax: 1-248.569.6567 > www.dss-corp.com > www.dispatchimprovement.com > > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Dave Higton > Sent: Friday, July 27, 2012 10:16 AM > To: siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > > I am accustomed to thinking that the choice to record mixed or unmixed media is made at time of placing a contract to purchase recording equipment. That places no requirement to specify at recording time. > > Is there, therefore, a case for saying that SIPREC does not need to support such a choice? > > Dave > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Michael Smith > Sent: 27 July 2012 14:28 > To: siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > > So Ram proposes: > We can have an SRC that does one or more of the following: > 1)An SRC MAY support sending unmixed media only > 2) An SRC supports sending mixed media only (the case of conference where SRC is a participant) > 3) An SRC supports sending mixed or unmixed media or both > > I'm curious - do others agree with that position? > > IMHO, the SRC conference participant case is a non-issue. If an SRC is a participant in a Bridge, the "mixed" media coming from the Bridge is a single stream from its point of view, and an SRS that wanted unmixed media would only get whatever streams the SRC had. > > Now, I would like to see the possibility of the SRS dictating (or at least indicating a desire for) mixed or unmixed media, but if the majority disagree, I can live with that. > > I do want to bring this up with the NENA NG9-1-1 recording test committee I chair. Nine recording companies participate, and I'd like to see if that group thinks we should impose additional requirements for an SRC/SRS used in an NG9-1-1 environment. I don't personally think that Public Safety needs are different than private sector needs on this issue, but it's a good discussion to have now. If there were no mechanism for the SRS to make its mixed/unmixed desire known, we'd have a problem to solve. Perhaps this group could define such a mechanism without requiring that it be used? > > > Thanks, > > Michael Smith > Chief Technologist > Ph: 606.877.2788 | Mobile: 606.231.0243 > > DSS Corporation / Equature > 18311 W. Ten Mile Road, Suite 200 > Southfield, MI - 48075 > Tel: 1-888.305.3428 > Fax: 1-248.569.6567 > www.dss-corp.com > www.dispatchimprovement.com > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) > Sent: Friday, July 27, 2012 12:45 AM > To: Paul Kyzivat; siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > >> On 27/07/12 6:16 AM, "Paul Kyzivat" wrote: > >> On 7/26/12 7:08 PM, Michael Smith wrote: >>> Hmmm... What's important is that the SRC supports unmixed streams. If >>> it does, the server could mix them, and policy is enforced at that >>> point. The drawback to that is that you consume twice the bandwidth >>> per CS, even if your policy is to store mixed streams. >>> >>> Good point about a phone, but they do already mix the two parties >>> voices. Mixing is simple, and not processing-intensive, so levying >>> that requirement on an SRC isn't onerous, IMHO. >>> >>> I'd be ok if an SRC didn't support mixing media, and the SRS mixed it. >>> But I think it's a problem if an SRC mixes media and policy dictates >>> that unmixed media be stored - there's no way to un-mix it. >> >> So what about an SRC connected to a focus of a conference with many >> participants. The SRC is only receiving a mixed stream from the focus, >> which includes all participants except itself. It can know who all the >> participants are (from the conference event package), but it can't pass >> them on unmixed. >> >>> I think requirements might be crafted that an SRS MUST support >>> receiving both mixed and unmixed media, and an SRC MUST support >>> sending unmixed media, and MAY support sending mixed media. You'd >>> still need some mechanism for negotiating mixed/unmixed. >> >> I'm going to stand by my prior opinion for now. >> >> As a customer I think you can *prefer* that things work this way. If >> you have buying control over the SRC you can specify that. But I don't >> think it makes sense to exclude SRCs that work otherwise. > > > I also agree with Paul. We can have an SRC that does one or more of the > following: > 1)An SRC MAY support sending unmixed media only > 2) An SRC supports sending mixed media only (the case of conference where SRC is a participant) > 3) An SRC supports sending mixed or unmixed media or both > > So its better not to restrict and there by exclude some SRCs. > > Ram > >> >> Thanks, >> Paul >> >>> Michael Smith >>> Chief Technologist >>> Ph: 606.877.2788 | Mobile: 606.231.0243 >>> >>> DSS Corporation / Equature >>> 18311 W. Ten Mile Road, Suite 200 >>> Southfield, MI - 48075 >>> Tel: 1-888.305.3428 >>> Fax: 1-248.569.6567 >>> www.dss-corp.com >>> www.dispatchimprovement.com >>> >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: Thursday, July 26, 2012 6:15 PM >>> To: siprec@ietf.org >>> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >>> >>> On 7/26/12 5:11 PM, Michael Smith wrote: >>>> I would think you'd want the SRS, as the recipient of the media, to >>>> decide whether it wants mixed or unmixed media. And that the SRC must >>>> support both, and must comply with the SRS's request. And that >>>> implies that you must have a mechanism for the SRC to tell the SRC >>>> whether it wants mixed or unmixed media. >>> >>> You are going to *require* that the SRC be able to do mixing??? >>> >>>> An SRS may receive from many SRCs. What I suggest above allows >>>> policy to be implemented in one place (the SRS), and forces all SRCs >>>> to comply with it. >>> >>> On the contrary, ISTM that the SRS is a *utility*, and one that >>> probably has considerable resources. It is providing a service to a >>> wide range of clients that may vary widely in their capabilities. >>> It makes much or sense to me that life is made as simple and flexible >>> as possible for the SRC. >>> >>> Leon indicated that some preliminary implementations prefer to >>> receive the streams unmixed. That is also perhaps easier for the SRC, >>> at the expense of requiring more bandwidth. Certainly its easier for a "phone" >>> that might have no mixing capability at all. OTOH there may be >>> devices that are very bandwidth limited that would prefer to mix first >>> to conserve the bandwidth. And there may be some devices, such as a >>> conference focus, for which mixing may be the most convenient way. And >>> of course there could be an SRC that is a *participant* in a >>> conference, that has no choice but to accept mixed media from the >>> focus, and so must pass it along unmixed to the SRS. >>> >>> Thanks, >>> Paul >>> >>>> Michael Smith >>>> Chief Technologist >>>> Ph: 606.877.2788 | Mobile: 606.231.0243 >>>> >>>> DSS Corporation / Equature >>>> 18311 W. Ten Mile Road, Suite 200 >>>> Southfield, MI - 48075 >>>> Tel: 1-888.305.3428 >>>> Fax: 1-248.569.6567 >>>> www.dss-corp.com >>>> www.dispatchimprovement.com >>>> >>>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of Leon Portman >>>> Sent: Thursday, July 26, 2012 4:59 PM >>>> To: Paul Kyzivat >>>> Cc: siprec@ietf.org >>>> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >>>> >>>> Paul Hi >>>> >>>> Generic comment: current implementations of SRS support to be >>>> configured either store unmixed media separately or mixed them on >>>> SRS side in order to save storage. >>>> On protocol side: we can define a negotiation of mixing like this: >>>> If SRC supports sending both mixed and unmixed medias, it can offer >>>> both in SDP as multiple m-lines and SRS can accept the preferred option. >>>> Of if it is specific policy on SRC side, SRS still can have option >>>> to mix if SRC always sends unmixed. >>>> >>>> What do you think? >>>> >>>> >>>> Leon >>>> >>>> On Jul 26, 2012, at 11:53 PM, Paul Kyzivat >>>> wrote: >>>> >>>>> One small comment on this: >>>>> >>>>> Section 3.2.4: >>>>> >>>>> When recording this media the two streams may be >>>>> mixed at the SRC before being transmitted to the SRS or it may >>>>> be a >>>>> requirement of the recording server that the media streams are not >>>>> mixed and are sent to the SRS as two separate streams. >>>>> >>>>> Do we really want to say that the SRS can decide that it must have >>>>> unmixed media??? >>>>> >>>>> I don't think so. IMO this should be solely at the discretion of >>>>> the SRC. >>>>> >>>>> If it was up to the SRS, how would it indicate this to the SRC? >>>>> _______________________________________________ >>>>> 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 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From prvs=1555156da9=MSmith@dss-corp.com Fri Jul 27 07:55: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 202EA21F8720 for ; Fri, 27 Jul 2012 07:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 af3op8ck7+f7 for ; Fri, 27 Jul 2012 07:55:02 -0700 (PDT) Received: from spam.dss-corp.com (spam.dss-corp.com [67.214.118.46]) by ietfa.amsl.com (Postfix) with ESMTP id B113421F871E for ; Fri, 27 Jul 2012 07:55:01 -0700 (PDT) Received: from spam.dss-corp.com (127.0.0.1) by spam.dss-corp.com (MlfMTA v3.2r9) id h2amna0171s9 for ; Fri, 27 Jul 2012 11:02:12 -0400 (envelope-from ) Received: from exc.dss-corp.com ([192.168.1.5]) by spam.dss-corp.com (SonicWALL 7.2.4.3929) with ESMTP; Fri, 27 Jul 2012 11:02:12 -0400 Received: from EXC01.dss.lan ([fe80::109b:ad4:1a47:2813]) by exc01.dss.lan ([fe80::109b:ad4:1a47:2813%13]) with mapi; Fri, 27 Jul 2012 10:54:57 -0400 From: Michael Smith To: "siprec@ietf.org" Thread-Topic: [siprec] Comments on draft-ietf-siprec-architecture-05 Thread-Index: AQHNa3Czt4ZtpSjdMEe219lQXs2A+5c8TyqA//++Z2CAAFbNAP//xgFggABkW4CAAEKLgIAASdxQgAARLICAAAGlgIAASs6A//++lAA= Date: Fri, 27 Jul 2012 14:54:38 +0000 Message-ID: <05D56509F27CCE4DAF8136C02386880D686CC517@exc01.dss.lan> References: <5011E4ED.1080101@alum.mit.edu> <05D56509F27CCE4DAF8136C02386880D686CBD5A@exc01.dss.lan> <9B0B6FB9606F4D4AB133C5E9A203B6940559DF494B@SOUEXC01.eu.nice.com> <05D56509F27CCE4DAF8136C02386880D686CC27E@exc01.dss.lan> <5012A93D.5020006@alum.mit.edu> In-Reply-To: <5012A93D.5020006@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mlf-Version: 7.2.4.3929 X-Mlf-UniqueId: o201207271502120085812 Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 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, 27 Jul 2012 14:55:03 -0000 Hmmm... perhaps this discussion should be future work? I'm not sure the gro= up would want to get into something new that is potentially complex at this= point. I was thinking a mechanism would be fairly straightforward. Perhaps it's no= t. Michael Smith Chief Technologist Ph: 606.877.2788 | Mobile: 606.231.0243=20 DSS Corporation / Equature 18311=A0=A0 W. Ten Mile Road, Suite 200 Southfield, MI - 48075 Tel: 1-888.305.3428 Fax: 1-248.569.6567 www.dss-corp.com www.dispatchimprovement.com -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: Friday, July 27, 2012 10:44 AM To: siprec@ietf.org Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 On 7/27/12 10:26 AM, Michael Smith wrote: > Yeah, I think Paul made the case that a customer can buy an SRC that supp= orts sending mixed, unmixed or both. But without some requirement, we don't= know what vendors will produce, and you can only buy what's available. > > I'm ok with the proposal Paul and Ram made, as long as we're all ok with = the possibility that SRC vendors might offer only mixed, or conversely, onl= y unmixed. Either could happen, but I suspect the "mixed only" option would= be what we'd end up with - and that's the problem. The server doesn't even= have a choice if that's all the SRC offers. It can only record mixed media= . > > BTW, I looked at the current NENA 08-003 draft. It looks like we dropped = the sentence we initially had about recording unmixed media, perhaps for th= e same reasons Paul and Ram have presented. > > I still would like to have some mechanism for the SRS to make its desire = for mixed or unmixed known, and then say that it MAY be used, and the SRC M= AY comply with the request. I think that's better than nothing. I am agreeable with having some discussion of how the SRS can express some = preferences to the SRC. It doesn't seem to fit well within the communicatio= n framework we have defined so far, so it might require some significant ch= anges. One problem is that currently its possible for the SRC to send an INVITE to= initiate an RS, with an SDP offer and metadata describing what it wants re= corded initially. The construction of that offer and the metadata already e= mbodies a policy decision about how to do the recording - whether mixed or = unmixed. And at that time there has been *no* opportunity for the SRS to indicate its preferences. And I've been led= to believe its important that things work this way so that a recording can= be established rapidly. Thanks, Paul > Michael Smith > Chief Technologist > Ph: 606.877.2788 | Mobile: 606.231.0243 > > DSS Corporation / Equature > 18311 W. Ten Mile Road, Suite 200 > Southfield, MI - 48075 > Tel: 1-888.305.3428 > Fax: 1-248.569.6567 > www.dss-corp.com > www.dispatchimprovement.com > > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Dave Higton > Sent: Friday, July 27, 2012 10:16 AM > To: siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > > I am accustomed to thinking that the choice to record mixed or unmixed me= dia is made at time of placing a contract to purchase recording equipment. = That places no requirement to specify at recording time. > > Is there, therefore, a case for saying that SIPREC does not need to suppo= rt such a choice? > > Dave > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Michael Smith > Sent: 27 July 2012 14:28 > To: siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > > So Ram proposes: > We can have an SRC that does one or more of the following: > 1)An SRC MAY support sending unmixed media only > 2) An SRC supports sending mixed media only (the case of conference = where SRC is a participant) > 3) An SRC supports sending mixed or unmixed media or both > > I'm curious - do others agree with that position? > > IMHO, the SRC conference participant case is a non-issue. If an SRC is a = participant in a Bridge, the "mixed" media coming from the Bridge is a sing= le stream from its point of view, and an SRS that wanted unmixed media woul= d only get whatever streams the SRC had. > > Now, I would like to see the possibility of the SRS dictating (or at leas= t indicating a desire for) mixed or unmixed media, but if the majority disa= gree, I can live with that. > > I do want to bring this up with the NENA NG9-1-1 recording test committee= I chair. Nine recording companies participate, and I'd like to see if that= group thinks we should impose additional requirements for an SRC/SRS used = in an NG9-1-1 environment. I don't personally think that Public Safety need= s are different than private sector needs on this issue, but it's a good di= scussion to have now. If there were no mechanism for the SRS to make its mi= xed/unmixed desire known, we'd have a problem to solve. Perhaps this group = could define such a mechanism without requiring that it be used? > > > Thanks, > > Michael Smith > Chief Technologist > Ph: 606.877.2788 | Mobile: 606.231.0243 > > DSS Corporation / Equature > 18311 W. Ten Mile Road, Suite 200 > Southfield, MI - 48075 > Tel: 1-888.305.3428 > Fax: 1-248.569.6567 > www.dss-corp.com > www.dispatchimprovement.com > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Ram Mohan R (rmohanr) > Sent: Friday, July 27, 2012 12:45 AM > To: Paul Kyzivat; siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > >> On 27/07/12 6:16 AM, "Paul Kyzivat" wrote: > >> On 7/26/12 7:08 PM, Michael Smith wrote: >>> Hmmm... What's important is that the SRC supports unmixed streams.=20 >>> If it does, the server could mix them, and policy is enforced at=20 >>> that point. The drawback to that is that you consume twice the=20 >>> bandwidth per CS, even if your policy is to store mixed streams. >>> >>> Good point about a phone, but they do already mix the two parties=20 >>> voices. Mixing is simple, and not processing-intensive, so levying=20 >>> that requirement on an SRC isn't onerous, IMHO. >>> >>> I'd be ok if an SRC didn't support mixing media, and the SRS mixed it. >>> But I think it's a problem if an SRC mixes media and policy dictates=20 >>> that unmixed media be stored - there's no way to un-mix it. >> >> So what about an SRC connected to a focus of a conference with many=20 >> participants. The SRC is only receiving a mixed stream from the=20 >> focus, which includes all participants except itself. It can know who=20 >> all the participants are (from the conference event package), but it=20 >> can't pass them on unmixed. >> >>> I think requirements might be crafted that an SRS MUST support=20 >>> receiving both mixed and unmixed media, and an SRC MUST support=20 >>> sending unmixed media, and MAY support sending mixed media. You'd=20 >>> still need some mechanism for negotiating mixed/unmixed. >> >> I'm going to stand by my prior opinion for now. >> >> As a customer I think you can *prefer* that things work this way. If=20 >> you have buying control over the SRC you can specify that. But I=20 >> don't think it makes sense to exclude SRCs that work otherwise. > > > I also agree with Paul. We can have an SRC that does one or more of=20 > the > following: > 1)An SRC MAY support sending unmixed media only > 2) An SRC supports sending mixed media only (the case of conference=20 > where SRC is a participant) > 3) An SRC supports sending mixed or unmixed media or both > > So its better not to restrict and there by exclude some SRCs. > > Ram > >> >> Thanks, >> Paul >> >>> Michael Smith >>> Chief Technologist >>> Ph: 606.877.2788 | Mobile: 606.231.0243 >>> >>> DSS Corporation / Equature >>> 18311 W. Ten Mile Road, Suite 200 >>> Southfield, MI - 48075 >>> Tel: 1-888.305.3428 >>> Fax: 1-248.569.6567 >>> www.dss-corp.com >>> www.dispatchimprovement.com >>> >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>> Behalf Of Paul Kyzivat >>> Sent: Thursday, July 26, 2012 6:15 PM >>> To: siprec@ietf.org >>> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >>> >>> On 7/26/12 5:11 PM, Michael Smith wrote: >>>> I would think you'd want the SRS, as the recipient of the media, to=20 >>>> decide whether it wants mixed or unmixed media. And that the SRC=20 >>>> must support both, and must comply with the SRS's request. And that=20 >>>> implies that you must have a mechanism for the SRC to tell the SRC=20 >>>> whether it wants mixed or unmixed media. >>> >>> You are going to *require* that the SRC be able to do mixing??? >>> >>>> An SRS may receive from many SRCs. What I suggest above allows=20 >>>> policy to be implemented in one place (the SRS), and forces all=20 >>>> SRCs to comply with it. >>> >>> On the contrary, ISTM that the SRS is a *utility*, and one that=20 >>> probably has considerable resources. It is providing a service to a=20 >>> wide range of clients that may vary widely in their capabilities. >>> It makes much or sense to me that life is made as simple and=20 >>> flexible as possible for the SRC. >>> >>> Leon indicated that some preliminary implementations prefer to=20 >>> receive the streams unmixed. That is also perhaps easier for the=20 >>> SRC, at the expense of requiring more bandwidth. Certainly its easier f= or a "phone" >>> that might have no mixing capability at all. OTOH there may be=20 >>> devices that are very bandwidth limited that would prefer to mix=20 >>> first to conserve the bandwidth. And there may be some devices, such=20 >>> as a conference focus, for which mixing may be the most convenient=20 >>> way. And of course there could be an SRC that is a *participant* in=20 >>> a conference, that has no choice but to accept mixed media from the=20 >>> focus, and so must pass it along unmixed to the SRS. >>> >>> Thanks, >>> Paul >>> >>>> Michael Smith >>>> Chief Technologist >>>> Ph: 606.877.2788 | Mobile: 606.231.0243 >>>> >>>> DSS Corporation / Equature >>>> 18311 W. Ten Mile Road, Suite 200 >>>> Southfield, MI - 48075 >>>> Tel: 1-888.305.3428 >>>> Fax: 1-248.569.6567 >>>> www.dss-corp.com >>>> www.dispatchimprovement.com >>>> >>>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>>> Behalf Of Leon Portman >>>> Sent: Thursday, July 26, 2012 4:59 PM >>>> To: Paul Kyzivat >>>> Cc: siprec@ietf.org >>>> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >>>> >>>> Paul Hi >>>> >>>> Generic comment: current implementations of SRS support to be=20 >>>> configured either store unmixed media separately or mixed them on=20 >>>> SRS side in order to save storage. >>>> On protocol side: we can define a negotiation of mixing like this: >>>> If SRC supports sending both mixed and unmixed medias, it can offer=20 >>>> both in SDP as multiple m-lines and SRS can accept the preferred optio= n. >>>> Of if it is specific policy on SRC side, SRS still can have option=20 >>>> to mix if SRC always sends unmixed. >>>> >>>> What do you think? >>>> >>>> >>>> Leon >>>> >>>> On Jul 26, 2012, at 11:53 PM, Paul Kyzivat >>>> wrote: >>>> >>>>> One small comment on this: >>>>> >>>>> Section 3.2.4: >>>>> >>>>> When recording this media the two streams may be >>>>> mixed at the SRC before being transmitted to the SRS or it=20 >>>>> may be a >>>>> requirement of the recording server that the media streams are n= ot >>>>> mixed and are sent to the SRS as two separate streams. >>>>> >>>>> Do we really want to say that the SRS can decide that it must have=20 >>>>> unmixed media??? >>>>> >>>>> I don't think so. IMO this should be solely at the discretion of=20 >>>>> the SRC. >>>>> >>>>> If it was up to the SRS, how would it indicate this to the SRC? >>>>> _______________________________________________ >>>>> 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 > _______________________________________________ > 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 prvs=1555156da9=MSmith@dss-corp.com Fri Jul 27 07:59: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 7520A21F8754 for ; Fri, 27 Jul 2012 07:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 LcStr2-xtny5 for ; Fri, 27 Jul 2012 07:59:32 -0700 (PDT) Received: from spam.dss-corp.com (spam.dss-corp.com [67.214.118.46]) by ietfa.amsl.com (Postfix) with ESMTP id EBA8D21F8753 for ; Fri, 27 Jul 2012 07:59:31 -0700 (PDT) Received: from spam.dss-corp.com (127.0.0.1) by spam.dss-corp.com (MlfMTA v3.2r9) id h2an860171sr for ; Fri, 27 Jul 2012 11:06:43 -0400 (envelope-from ) Received: from exc.dss-corp.com ([192.168.1.5]) by spam.dss-corp.com (SonicWALL 7.2.4.3929) with ESMTP; Fri, 27 Jul 2012 11:06:42 -0400 Received: from EXC01.dss.lan ([fe80::109b:ad4:1a47:2813]) by exc01.dss.lan ([fe80::109b:ad4:1a47:2813%13]) with mapi; Fri, 27 Jul 2012 10:59:29 -0400 From: Michael Smith To: "siprec@ietf.org" Thread-Topic: [siprec] Comments on draft-ietf-siprec-architecture-05 Thread-Index: AQHNa3Czt4ZtpSjdMEe219lQXs2A+5c8TyqA//++Z2CAAFbNAP//xgFggABkW4CAAEKLgIAASdxQgAARLICAAAGlgIAASs6A//++lAAAAETDQA== Date: Fri, 27 Jul 2012 14:59:09 +0000 Message-ID: <05D56509F27CCE4DAF8136C02386880D686CC57B@exc01.dss.lan> References: <5011E4ED.1080101@alum.mit.edu> <05D56509F27CCE4DAF8136C02386880D686CBD5A@exc01.dss.lan> <9B0B6FB9606F4D4AB133C5E9A203B6940559DF494B@SOUEXC01.eu.nice.com> <05D56509F27CCE4DAF8136C02386880D686CC27E@exc01.dss.lan> <5012A93D.5020006@alum.mit.edu> <05D56509F27CCE4DAF8136C02386880D686CC517@exc01.dss.lan> In-Reply-To: <05D56509F27CCE4DAF8136C02386880D686CC517@exc01.dss.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mlf-Version: 7.2.4.3929 X-Mlf-UniqueId: o201207271506420085840 Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 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, 27 Jul 2012 14:59:33 -0000 And when the discussion does occur at some point, I think the Options metho= d might provide the framework for an SRC to discover what the desire of an = SRS is. Michael Smith Chief Technologist Ph: 606.877.2788 | Mobile: 606.231.0243 DSS Corporation / Equature 18311 W. Ten Mile Road, Suite 200 Southfield, MI - 48075 Tel: 1-888.305.3428 Fax: 1-248.569.6567 www.dss-corp.com www.dispatchimprovement.com -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Michael Smith Sent: Friday, July 27, 2012 10:55 AM To: siprec@ietf.org Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 Hmmm... perhaps this discussion should be future work? I'm not sure the gro= up would want to get into something new that is potentially complex at this= point. I was thinking a mechanism would be fairly straightforward. Perhaps it's no= t. Michael Smith Chief Technologist Ph: 606.877.2788 | Mobile: 606.231.0243 DSS Corporation / Equature 18311 W. Ten Mile Road, Suite 200 Southfield, MI - 48075 Tel: 1-888.305.3428 Fax: 1-248.569.6567 www.dss-corp.com www.dispatchimprovement.com -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: Friday, July 27, 2012 10:44 AM To: siprec@ietf.org Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 On 7/27/12 10:26 AM, Michael Smith wrote: > Yeah, I think Paul made the case that a customer can buy an SRC that supp= orts sending mixed, unmixed or both. But without some requirement, we don't= know what vendors will produce, and you can only buy what's available. > > I'm ok with the proposal Paul and Ram made, as long as we're all ok with = the possibility that SRC vendors might offer only mixed, or conversely, onl= y unmixed. Either could happen, but I suspect the "mixed only" option would= be what we'd end up with - and that's the problem. The server doesn't even= have a choice if that's all the SRC offers. It can only record mixed media= . > > BTW, I looked at the current NENA 08-003 draft. It looks like we dropped = the sentence we initially had about recording unmixed media, perhaps for th= e same reasons Paul and Ram have presented. > > I still would like to have some mechanism for the SRS to make its desire = for mixed or unmixed known, and then say that it MAY be used, and the SRC M= AY comply with the request. I think that's better than nothing. I am agreeable with having some discussion of how the SRS can express some = preferences to the SRC. It doesn't seem to fit well within the communicatio= n framework we have defined so far, so it might require some significant ch= anges. One problem is that currently its possible for the SRC to send an INVITE to= initiate an RS, with an SDP offer and metadata describing what it wants re= corded initially. The construction of that offer and the metadata already e= mbodies a policy decision about how to do the recording - whether mixed or = unmixed. And at that time there has been *no* opportunity for the SRS to indicate its preferences. And I've been led= to believe its important that things work this way so that a recording can= be established rapidly. Thanks, Paul > Michael Smith > Chief Technologist > Ph: 606.877.2788 | Mobile: 606.231.0243 > > DSS Corporation / Equature > 18311 W. Ten Mile Road, Suite 200 > Southfield, MI - 48075 > Tel: 1-888.305.3428 > Fax: 1-248.569.6567 > www.dss-corp.com > www.dispatchimprovement.com > > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Dave Higton > Sent: Friday, July 27, 2012 10:16 AM > To: siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > > I am accustomed to thinking that the choice to record mixed or unmixed me= dia is made at time of placing a contract to purchase recording equipment. = That places no requirement to specify at recording time. > > Is there, therefore, a case for saying that SIPREC does not need to suppo= rt such a choice? > > Dave > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Michael Smith > Sent: 27 July 2012 14:28 > To: siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > > So Ram proposes: > We can have an SRC that does one or more of the following: > 1)An SRC MAY support sending unmixed media only > 2) An SRC supports sending mixed media only (the case of conference = where SRC is a participant) > 3) An SRC supports sending mixed or unmixed media or both > > I'm curious - do others agree with that position? > > IMHO, the SRC conference participant case is a non-issue. If an SRC is a = participant in a Bridge, the "mixed" media coming from the Bridge is a sing= le stream from its point of view, and an SRS that wanted unmixed media woul= d only get whatever streams the SRC had. > > Now, I would like to see the possibility of the SRS dictating (or at leas= t indicating a desire for) mixed or unmixed media, but if the majority disa= gree, I can live with that. > > I do want to bring this up with the NENA NG9-1-1 recording test committee= I chair. Nine recording companies participate, and I'd like to see if that= group thinks we should impose additional requirements for an SRC/SRS used = in an NG9-1-1 environment. I don't personally think that Public Safety need= s are different than private sector needs on this issue, but it's a good di= scussion to have now. If there were no mechanism for the SRS to make its mi= xed/unmixed desire known, we'd have a problem to solve. Perhaps this group = could define such a mechanism without requiring that it be used? > > > Thanks, > > Michael Smith > Chief Technologist > Ph: 606.877.2788 | Mobile: 606.231.0243 > > DSS Corporation / Equature > 18311 W. Ten Mile Road, Suite 200 > Southfield, MI - 48075 > Tel: 1-888.305.3428 > Fax: 1-248.569.6567 > www.dss-corp.com > www.dispatchimprovement.com > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ram Mohan R (rmohanr) > Sent: Friday, July 27, 2012 12:45 AM > To: Paul Kyzivat; siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > >> On 27/07/12 6:16 AM, "Paul Kyzivat" wrote: > >> On 7/26/12 7:08 PM, Michael Smith wrote: >>> Hmmm... What's important is that the SRC supports unmixed streams. >>> If it does, the server could mix them, and policy is enforced at >>> that point. The drawback to that is that you consume twice the >>> bandwidth per CS, even if your policy is to store mixed streams. >>> >>> Good point about a phone, but they do already mix the two parties >>> voices. Mixing is simple, and not processing-intensive, so levying >>> that requirement on an SRC isn't onerous, IMHO. >>> >>> I'd be ok if an SRC didn't support mixing media, and the SRS mixed it. >>> But I think it's a problem if an SRC mixes media and policy dictates >>> that unmixed media be stored - there's no way to un-mix it. >> >> So what about an SRC connected to a focus of a conference with many >> participants. The SRC is only receiving a mixed stream from the >> focus, which includes all participants except itself. It can know who >> all the participants are (from the conference event package), but it >> can't pass them on unmixed. >> >>> I think requirements might be crafted that an SRS MUST support >>> receiving both mixed and unmixed media, and an SRC MUST support >>> sending unmixed media, and MAY support sending mixed media. You'd >>> still need some mechanism for negotiating mixed/unmixed. >> >> I'm going to stand by my prior opinion for now. >> >> As a customer I think you can *prefer* that things work this way. If >> you have buying control over the SRC you can specify that. But I >> don't think it makes sense to exclude SRCs that work otherwise. > > > I also agree with Paul. We can have an SRC that does one or more of > the > following: > 1)An SRC MAY support sending unmixed media only > 2) An SRC supports sending mixed media only (the case of conference > where SRC is a participant) > 3) An SRC supports sending mixed or unmixed media or both > > So its better not to restrict and there by exclude some SRCs. > > Ram > >> >> Thanks, >> Paul >> >>> Michael Smith >>> Chief Technologist >>> Ph: 606.877.2788 | Mobile: 606.231.0243 >>> >>> DSS Corporation / Equature >>> 18311 W. Ten Mile Road, Suite 200 >>> Southfield, MI - 48075 >>> Tel: 1-888.305.3428 >>> Fax: 1-248.569.6567 >>> www.dss-corp.com >>> www.dispatchimprovement.com >>> >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: Thursday, July 26, 2012 6:15 PM >>> To: siprec@ietf.org >>> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >>> >>> On 7/26/12 5:11 PM, Michael Smith wrote: >>>> I would think you'd want the SRS, as the recipient of the media, to >>>> decide whether it wants mixed or unmixed media. And that the SRC >>>> must support both, and must comply with the SRS's request. And that >>>> implies that you must have a mechanism for the SRC to tell the SRC >>>> whether it wants mixed or unmixed media. >>> >>> You are going to *require* that the SRC be able to do mixing??? >>> >>>> An SRS may receive from many SRCs. What I suggest above allows >>>> policy to be implemented in one place (the SRS), and forces all >>>> SRCs to comply with it. >>> >>> On the contrary, ISTM that the SRS is a *utility*, and one that >>> probably has considerable resources. It is providing a service to a >>> wide range of clients that may vary widely in their capabilities. >>> It makes much or sense to me that life is made as simple and >>> flexible as possible for the SRC. >>> >>> Leon indicated that some preliminary implementations prefer to >>> receive the streams unmixed. That is also perhaps easier for the >>> SRC, at the expense of requiring more bandwidth. Certainly its easier f= or a "phone" >>> that might have no mixing capability at all. OTOH there may be >>> devices that are very bandwidth limited that would prefer to mix >>> first to conserve the bandwidth. And there may be some devices, such >>> as a conference focus, for which mixing may be the most convenient >>> way. And of course there could be an SRC that is a *participant* in >>> a conference, that has no choice but to accept mixed media from the >>> focus, and so must pass it along unmixed to the SRS. >>> >>> Thanks, >>> Paul >>> >>>> Michael Smith >>>> Chief Technologist >>>> Ph: 606.877.2788 | Mobile: 606.231.0243 >>>> >>>> DSS Corporation / Equature >>>> 18311 W. Ten Mile Road, Suite 200 >>>> Southfield, MI - 48075 >>>> Tel: 1-888.305.3428 >>>> Fax: 1-248.569.6567 >>>> www.dss-corp.com >>>> www.dispatchimprovement.com >>>> >>>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of Leon Portman >>>> Sent: Thursday, July 26, 2012 4:59 PM >>>> To: Paul Kyzivat >>>> Cc: siprec@ietf.org >>>> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >>>> >>>> Paul Hi >>>> >>>> Generic comment: current implementations of SRS support to be >>>> configured either store unmixed media separately or mixed them on >>>> SRS side in order to save storage. >>>> On protocol side: we can define a negotiation of mixing like this: >>>> If SRC supports sending both mixed and unmixed medias, it can offer >>>> both in SDP as multiple m-lines and SRS can accept the preferred optio= n. >>>> Of if it is specific policy on SRC side, SRS still can have option >>>> to mix if SRC always sends unmixed. >>>> >>>> What do you think? >>>> >>>> >>>> Leon >>>> >>>> On Jul 26, 2012, at 11:53 PM, Paul Kyzivat >>>> wrote: >>>> >>>>> One small comment on this: >>>>> >>>>> Section 3.2.4: >>>>> >>>>> When recording this media the two streams may be >>>>> mixed at the SRC before being transmitted to the SRS or it >>>>> may be a >>>>> requirement of the recording server that the media streams are n= ot >>>>> mixed and are sent to the SRS as two separate streams. >>>>> >>>>> Do we really want to say that the SRS can decide that it must have >>>>> unmixed media??? >>>>> >>>>> I don't think so. IMO this should be solely at the discretion of >>>>> the SRC. >>>>> >>>>> If it was up to the SRS, how would it indicate this to the SRC? >>>>> _______________________________________________ >>>>> 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 > _______________________________________________ > 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 DAVE.HIGTON@nice.com Fri Jul 27 08:01:00 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 EC38E21F877D for ; Fri, 27 Jul 2012 08:01:00 -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 ig2c4ynFsz9o for ; Fri, 27 Jul 2012 08:00:59 -0700 (PDT) Received: from soumd01.eu.nice.com (UKEmail.nice.com [195.166.55.162]) by ietfa.amsl.com (Postfix) with ESMTP id 083DB21F877B for ; Fri, 27 Jul 2012 08:00:58 -0700 (PDT) Received: from SOUCAS01.eu.nice.com ([10.1.1.9]) by soumd01.eu.nice.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jul 2012 16:00:57 +0100 Received: from SOUEXC01.eu.nice.com ([fe80::ec6d:6017:186e:e8f8]) by SOUCAS01.eu.nice.com ([::1]) with mapi; Fri, 27 Jul 2012 16:00:57 +0100 From: Dave Higton To: "siprec@ietf.org" Date: Fri, 27 Jul 2012 16:00:56 +0100 Thread-Topic: [siprec] Comments on draft-ietf-siprec-architecture-05 Thread-Index: AQHNa3Czt4ZtpSjdMEe219lQXs2A+5c8TyqA//++Z2CAAFbNAP//xgFggABkW4CAAEKLgIAASdxQgAARLICAAAGlgIAASs6A//++lAAAAETDQAAAF7lg Message-ID: <9B0B6FB9606F4D4AB133C5E9A203B6940559DF495C@SOUEXC01.eu.nice.com> References: <5011E4ED.1080101@alum.mit.edu> <05D56509F27CCE4DAF8136C02386880D686CBD5A@exc01.dss.lan> <9B0B6FB9606F4D4AB133C5E9A203B6940559DF494B@SOUEXC01.eu.nice.com> <05D56509F27CCE4DAF8136C02386880D686CC27E@exc01.dss.lan> <5012A93D.5020006@alum.mit.edu> <05D56509F27CCE4DAF8136C02386880D686CC517@exc01.dss.lan> <05D56509F27CCE4DAF8136C02386880D686CC57B@exc01.dss.lan> In-Reply-To: <05D56509F27CCE4DAF8136C02386880D686CC57B@exc01.dss.lan> 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 X-OriginalArrivalTime: 27 Jul 2012 15:00:57.0885 (UTC) FILETIME=[A0EA24D0:01CD6C08] Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 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, 27 Jul 2012 15:01:01 -0000 That seems to me to make a good deal of sense. Dave -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Michael Smith Sent: 27 July 2012 15:59 To: siprec@ietf.org Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 And when the discussion does occur at some point, I think the Options metho= d might provide the framework for an SRC to discover what the desire of an = SRS is. Michael Smith Chief Technologist Ph: 606.877.2788 | Mobile: 606.231.0243 DSS Corporation / Equature 18311 W. Ten Mile Road, Suite 200 Southfield, MI - 48075 Tel: 1-888.305.3428 Fax: 1-248.569.6567 www.dss-corp.com www.dispatchimprovement.com -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Michael Smith Sent: Friday, July 27, 2012 10:55 AM To: siprec@ietf.org Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 Hmmm... perhaps this discussion should be future work? I'm not sure the gro= up would want to get into something new that is potentially complex at this= point. I was thinking a mechanism would be fairly straightforward. Perhaps it's no= t. Michael Smith Chief Technologist Ph: 606.877.2788 | Mobile: 606.231.0243 DSS Corporation / Equature 18311 W. Ten Mile Road, Suite 200 Southfield, MI - 48075 Tel: 1-888.305.3428 Fax: 1-248.569.6567 www.dss-corp.com www.dispatchimprovement.com -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: Friday, July 27, 2012 10:44 AM To: siprec@ietf.org Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 On 7/27/12 10:26 AM, Michael Smith wrote: > Yeah, I think Paul made the case that a customer can buy an SRC that supp= orts sending mixed, unmixed or both. But without some requirement, we don't= know what vendors will produce, and you can only buy what's available. > > I'm ok with the proposal Paul and Ram made, as long as we're all ok with = the possibility that SRC vendors might offer only mixed, or conversely, onl= y unmixed. Either could happen, but I suspect the "mixed only" option would= be what we'd end up with - and that's the problem. The server doesn't even= have a choice if that's all the SRC offers. It can only record mixed media= . > > BTW, I looked at the current NENA 08-003 draft. It looks like we dropped = the sentence we initially had about recording unmixed media, perhaps for th= e same reasons Paul and Ram have presented. > > I still would like to have some mechanism for the SRS to make its desire = for mixed or unmixed known, and then say that it MAY be used, and the SRC M= AY comply with the request. I think that's better than nothing. I am agreeable with having some discussion of how the SRS can express some = preferences to the SRC. It doesn't seem to fit well within the communicatio= n framework we have defined so far, so it might require some significant ch= anges. One problem is that currently its possible for the SRC to send an INVITE to= initiate an RS, with an SDP offer and metadata describing what it wants re= corded initially. The construction of that offer and the metadata already e= mbodies a policy decision about how to do the recording - whether mixed or = unmixed. And at that time there has been *no* opportunity for the SRS to indicate its preferences. And I've been led= to believe its important that things work this way so that a recording can= be established rapidly. Thanks, Paul > Michael Smith > Chief Technologist > Ph: 606.877.2788 | Mobile: 606.231.0243 > > DSS Corporation / Equature > 18311 W. Ten Mile Road, Suite 200 > Southfield, MI - 48075 > Tel: 1-888.305.3428 > Fax: 1-248.569.6567 > www.dss-corp.com > www.dispatchimprovement.com > > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Dave Higton > Sent: Friday, July 27, 2012 10:16 AM > To: siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > > I am accustomed to thinking that the choice to record mixed or unmixed me= dia is made at time of placing a contract to purchase recording equipment. = That places no requirement to specify at recording time. > > Is there, therefore, a case for saying that SIPREC does not need to suppo= rt such a choice? > > Dave > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Michael Smith > Sent: 27 July 2012 14:28 > To: siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > > So Ram proposes: > We can have an SRC that does one or more of the following: > 1)An SRC MAY support sending unmixed media only > 2) An SRC supports sending mixed media only (the case of conference = where SRC is a participant) > 3) An SRC supports sending mixed or unmixed media or both > > I'm curious - do others agree with that position? > > IMHO, the SRC conference participant case is a non-issue. If an SRC is a = participant in a Bridge, the "mixed" media coming from the Bridge is a sing= le stream from its point of view, and an SRS that wanted unmixed media woul= d only get whatever streams the SRC had. > > Now, I would like to see the possibility of the SRS dictating (or at leas= t indicating a desire for) mixed or unmixed media, but if the majority disa= gree, I can live with that. > > I do want to bring this up with the NENA NG9-1-1 recording test committee= I chair. Nine recording companies participate, and I'd like to see if that= group thinks we should impose additional requirements for an SRC/SRS used = in an NG9-1-1 environment. I don't personally think that Public Safety need= s are different than private sector needs on this issue, but it's a good di= scussion to have now. If there were no mechanism for the SRS to make its mi= xed/unmixed desire known, we'd have a problem to solve. Perhaps this group = could define such a mechanism without requiring that it be used? > > > Thanks, > > Michael Smith > Chief Technologist > Ph: 606.877.2788 | Mobile: 606.231.0243 > > DSS Corporation / Equature > 18311 W. Ten Mile Road, Suite 200 > Southfield, MI - 48075 > Tel: 1-888.305.3428 > Fax: 1-248.569.6567 > www.dss-corp.com > www.dispatchimprovement.com > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ram Mohan R (rmohanr) > Sent: Friday, July 27, 2012 12:45 AM > To: Paul Kyzivat; siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > >> On 27/07/12 6:16 AM, "Paul Kyzivat" wrote: > >> On 7/26/12 7:08 PM, Michael Smith wrote: >>> Hmmm... What's important is that the SRC supports unmixed streams. >>> If it does, the server could mix them, and policy is enforced at >>> that point. The drawback to that is that you consume twice the >>> bandwidth per CS, even if your policy is to store mixed streams. >>> >>> Good point about a phone, but they do already mix the two parties >>> voices. Mixing is simple, and not processing-intensive, so levying >>> that requirement on an SRC isn't onerous, IMHO. >>> >>> I'd be ok if an SRC didn't support mixing media, and the SRS mixed it. >>> But I think it's a problem if an SRC mixes media and policy dictates >>> that unmixed media be stored - there's no way to un-mix it. >> >> So what about an SRC connected to a focus of a conference with many >> participants. The SRC is only receiving a mixed stream from the >> focus, which includes all participants except itself. It can know who >> all the participants are (from the conference event package), but it >> can't pass them on unmixed. >> >>> I think requirements might be crafted that an SRS MUST support >>> receiving both mixed and unmixed media, and an SRC MUST support >>> sending unmixed media, and MAY support sending mixed media. You'd >>> still need some mechanism for negotiating mixed/unmixed. >> >> I'm going to stand by my prior opinion for now. >> >> As a customer I think you can *prefer* that things work this way. If >> you have buying control over the SRC you can specify that. But I >> don't think it makes sense to exclude SRCs that work otherwise. > > > I also agree with Paul. We can have an SRC that does one or more of > the > following: > 1)An SRC MAY support sending unmixed media only > 2) An SRC supports sending mixed media only (the case of conference > where SRC is a participant) > 3) An SRC supports sending mixed or unmixed media or both > > So its better not to restrict and there by exclude some SRCs. > > Ram > >> >> Thanks, >> Paul >> >>> Michael Smith >>> Chief Technologist >>> Ph: 606.877.2788 | Mobile: 606.231.0243 >>> >>> DSS Corporation / Equature >>> 18311 W. Ten Mile Road, Suite 200 >>> Southfield, MI - 48075 >>> Tel: 1-888.305.3428 >>> Fax: 1-248.569.6567 >>> www.dss-corp.com >>> www.dispatchimprovement.com >>> >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: Thursday, July 26, 2012 6:15 PM >>> To: siprec@ietf.org >>> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >>> >>> On 7/26/12 5:11 PM, Michael Smith wrote: >>>> I would think you'd want the SRS, as the recipient of the media, to >>>> decide whether it wants mixed or unmixed media. And that the SRC >>>> must support both, and must comply with the SRS's request. And that >>>> implies that you must have a mechanism for the SRC to tell the SRC >>>> whether it wants mixed or unmixed media. >>> >>> You are going to *require* that the SRC be able to do mixing??? >>> >>>> An SRS may receive from many SRCs. What I suggest above allows >>>> policy to be implemented in one place (the SRS), and forces all >>>> SRCs to comply with it. >>> >>> On the contrary, ISTM that the SRS is a *utility*, and one that >>> probably has considerable resources. It is providing a service to a >>> wide range of clients that may vary widely in their capabilities. >>> It makes much or sense to me that life is made as simple and >>> flexible as possible for the SRC. >>> >>> Leon indicated that some preliminary implementations prefer to >>> receive the streams unmixed. That is also perhaps easier for the >>> SRC, at the expense of requiring more bandwidth. Certainly its easier f= or a "phone" >>> that might have no mixing capability at all. OTOH there may be >>> devices that are very bandwidth limited that would prefer to mix >>> first to conserve the bandwidth. And there may be some devices, such >>> as a conference focus, for which mixing may be the most convenient >>> way. And of course there could be an SRC that is a *participant* in >>> a conference, that has no choice but to accept mixed media from the >>> focus, and so must pass it along unmixed to the SRS. >>> >>> Thanks, >>> Paul >>> >>>> Michael Smith >>>> Chief Technologist >>>> Ph: 606.877.2788 | Mobile: 606.231.0243 >>>> >>>> DSS Corporation / Equature >>>> 18311 W. Ten Mile Road, Suite 200 >>>> Southfield, MI - 48075 >>>> Tel: 1-888.305.3428 >>>> Fax: 1-248.569.6567 >>>> www.dss-corp.com >>>> www.dispatchimprovement.com >>>> >>>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of Leon Portman >>>> Sent: Thursday, July 26, 2012 4:59 PM >>>> To: Paul Kyzivat >>>> Cc: siprec@ietf.org >>>> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >>>> >>>> Paul Hi >>>> >>>> Generic comment: current implementations of SRS support to be >>>> configured either store unmixed media separately or mixed them on >>>> SRS side in order to save storage. >>>> On protocol side: we can define a negotiation of mixing like this: >>>> If SRC supports sending both mixed and unmixed medias, it can offer >>>> both in SDP as multiple m-lines and SRS can accept the preferred optio= n. >>>> Of if it is specific policy on SRC side, SRS still can have option >>>> to mix if SRC always sends unmixed. >>>> >>>> What do you think? >>>> >>>> >>>> Leon >>>> >>>> On Jul 26, 2012, at 11:53 PM, Paul Kyzivat >>>> wrote: >>>> >>>>> One small comment on this: >>>>> >>>>> Section 3.2.4: >>>>> >>>>> When recording this media the two streams may be >>>>> mixed at the SRC before being transmitted to the SRS or it >>>>> may be a >>>>> requirement of the recording server that the media streams are n= ot >>>>> mixed and are sent to the SRS as two separate streams. >>>>> >>>>> Do we really want to say that the SRS can decide that it must have >>>>> unmixed media??? >>>>> >>>>> I don't think so. IMO this should be solely at the discretion of >>>>> the SRC. >>>>> >>>>> If it was up to the SRS, how would it indicate this to the SRC? >>>>> _______________________________________________ >>>>> 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 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Fri Jul 27 08:14: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 C080421F87F5 for ; Fri, 27 Jul 2012 08:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=0.292, 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 nJrObUNEwOG6 for ; Fri, 27 Jul 2012 08:14:36 -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 31E8921F87E8 for ; Fri, 27 Jul 2012 08:14:36 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta03.westchester.pa.mail.comcast.net with comcast id fQsy1j00C1swQuc53TEeqq; Fri, 27 Jul 2012 15:14:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id fTET1j0013ZTu2S3bTET6q; Fri, 27 Jul 2012 15:14:27 +0000 Message-ID: <5012B05A.3030001@alum.mit.edu> Date: Fri, 27 Jul 2012 11:14:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <5011E4ED.1080101@alum.mit.edu> <05D56509F27CCE4DAF8136C02386880D686CBD5A@exc01.dss.lan> <9B0B6FB9606F4D4AB133C5E9A203B6940559DF494B@SOUEXC01.eu.nice.com> <05D56509F27CCE4DAF8136C02386880D686CC27E@exc01.dss.lan> <5012A93D.5020006@alum.mit.edu> <05D56509F27CCE4DAF8136C02386880D686CC517@exc01.dss.lan> In-Reply-To: <05D56509F27CCE4DAF8136C02386880D686CC517@exc01.dss.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 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, 27 Jul 2012 15:14:37 -0000 On 7/27/12 10:54 AM, Michael Smith wrote: > Hmmm... perhaps this discussion should be future work? I'm not sure the group would want to get into something new that is potentially complex at this point. > > I was thinking a mechanism would be fairly straightforward. Perhaps it's not. Maybe we will have some time to discuss this as part of the architecture or protocol discussion. But maybe not - there isn't a lot of time. Do the chairs have an opinion on this? Thanks, Paul > Michael Smith > Chief Technologist > Ph: 606.877.2788 | Mobile: 606.231.0243 > > DSS Corporation / Equature > 18311 W. Ten Mile Road, Suite 200 > Southfield, MI - 48075 > Tel: 1-888.305.3428 > Fax: 1-248.569.6567 > www.dss-corp.com > www.dispatchimprovement.com > > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Friday, July 27, 2012 10:44 AM > To: siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > > On 7/27/12 10:26 AM, Michael Smith wrote: >> Yeah, I think Paul made the case that a customer can buy an SRC that supports sending mixed, unmixed or both. But without some requirement, we don't know what vendors will produce, and you can only buy what's available. >> >> I'm ok with the proposal Paul and Ram made, as long as we're all ok with the possibility that SRC vendors might offer only mixed, or conversely, only unmixed. Either could happen, but I suspect the "mixed only" option would be what we'd end up with - and that's the problem. The server doesn't even have a choice if that's all the SRC offers. It can only record mixed media. >> >> BTW, I looked at the current NENA 08-003 draft. It looks like we dropped the sentence we initially had about recording unmixed media, perhaps for the same reasons Paul and Ram have presented. >> >> I still would like to have some mechanism for the SRS to make its desire for mixed or unmixed known, and then say that it MAY be used, and the SRC MAY comply with the request. I think that's better than nothing. > > I am agreeable with having some discussion of how the SRS can express some preferences to the SRC. It doesn't seem to fit well within the communication framework we have defined so far, so it might require some significant changes. > > One problem is that currently its possible for the SRC to send an INVITE to initiate an RS, with an SDP offer and metadata describing what it wants recorded initially. The construction of that offer and the metadata already embodies a policy decision about how to do the recording - whether mixed or unmixed. And at that time there has been > *no* opportunity for the SRS to indicate its preferences. And I've been led to believe its important that things work this way so that a recording can be established rapidly. > > Thanks, > Paul > >> Michael Smith >> Chief Technologist >> Ph: 606.877.2788 | Mobile: 606.231.0243 >> >> DSS Corporation / Equature >> 18311 W. Ten Mile Road, Suite 200 >> Southfield, MI - 48075 >> Tel: 1-888.305.3428 >> Fax: 1-248.569.6567 >> www.dss-corp.com >> www.dispatchimprovement.com >> >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Dave Higton >> Sent: Friday, July 27, 2012 10:16 AM >> To: siprec@ietf.org >> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >> >> I am accustomed to thinking that the choice to record mixed or unmixed media is made at time of placing a contract to purchase recording equipment. That places no requirement to specify at recording time. >> >> Is there, therefore, a case for saying that SIPREC does not need to support such a choice? >> >> Dave >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Michael Smith >> Sent: 27 July 2012 14:28 >> To: siprec@ietf.org >> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >> >> So Ram proposes: >> We can have an SRC that does one or more of the following: >> 1)An SRC MAY support sending unmixed media only >> 2) An SRC supports sending mixed media only (the case of conference where SRC is a participant) >> 3) An SRC supports sending mixed or unmixed media or both >> >> I'm curious - do others agree with that position? >> >> IMHO, the SRC conference participant case is a non-issue. If an SRC is a participant in a Bridge, the "mixed" media coming from the Bridge is a single stream from its point of view, and an SRS that wanted unmixed media would only get whatever streams the SRC had. >> >> Now, I would like to see the possibility of the SRS dictating (or at least indicating a desire for) mixed or unmixed media, but if the majority disagree, I can live with that. >> >> I do want to bring this up with the NENA NG9-1-1 recording test committee I chair. Nine recording companies participate, and I'd like to see if that group thinks we should impose additional requirements for an SRC/SRS used in an NG9-1-1 environment. I don't personally think that Public Safety needs are different than private sector needs on this issue, but it's a good discussion to have now. If there were no mechanism for the SRS to make its mixed/unmixed desire known, we'd have a problem to solve. Perhaps this group could define such a mechanism without requiring that it be used? >> >> >> Thanks, >> >> Michael Smith >> Chief Technologist >> Ph: 606.877.2788 | Mobile: 606.231.0243 >> >> DSS Corporation / Equature >> 18311 W. Ten Mile Road, Suite 200 >> Southfield, MI - 48075 >> Tel: 1-888.305.3428 >> Fax: 1-248.569.6567 >> www.dss-corp.com >> www.dispatchimprovement.com >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Ram Mohan R (rmohanr) >> Sent: Friday, July 27, 2012 12:45 AM >> To: Paul Kyzivat; siprec@ietf.org >> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >> >>> On 27/07/12 6:16 AM, "Paul Kyzivat" wrote: >> >>> On 7/26/12 7:08 PM, Michael Smith wrote: >>>> Hmmm... What's important is that the SRC supports unmixed streams. >>>> If it does, the server could mix them, and policy is enforced at >>>> that point. The drawback to that is that you consume twice the >>>> bandwidth per CS, even if your policy is to store mixed streams. >>>> >>>> Good point about a phone, but they do already mix the two parties >>>> voices. Mixing is simple, and not processing-intensive, so levying >>>> that requirement on an SRC isn't onerous, IMHO. >>>> >>>> I'd be ok if an SRC didn't support mixing media, and the SRS mixed it. >>>> But I think it's a problem if an SRC mixes media and policy dictates >>>> that unmixed media be stored - there's no way to un-mix it. >>> >>> So what about an SRC connected to a focus of a conference with many >>> participants. The SRC is only receiving a mixed stream from the >>> focus, which includes all participants except itself. It can know who >>> all the participants are (from the conference event package), but it >>> can't pass them on unmixed. >>> >>>> I think requirements might be crafted that an SRS MUST support >>>> receiving both mixed and unmixed media, and an SRC MUST support >>>> sending unmixed media, and MAY support sending mixed media. You'd >>>> still need some mechanism for negotiating mixed/unmixed. >>> >>> I'm going to stand by my prior opinion for now. >>> >>> As a customer I think you can *prefer* that things work this way. If >>> you have buying control over the SRC you can specify that. But I >>> don't think it makes sense to exclude SRCs that work otherwise. >> >> >> I also agree with Paul. We can have an SRC that does one or more of >> the >> following: >> 1)An SRC MAY support sending unmixed media only >> 2) An SRC supports sending mixed media only (the case of conference >> where SRC is a participant) >> 3) An SRC supports sending mixed or unmixed media or both >> >> So its better not to restrict and there by exclude some SRCs. >> >> Ram >> >>> >>> Thanks, >>> Paul >>> >>>> Michael Smith >>>> Chief Technologist >>>> Ph: 606.877.2788 | Mobile: 606.231.0243 >>>> >>>> DSS Corporation / Equature >>>> 18311 W. Ten Mile Road, Suite 200 >>>> Southfield, MI - 48075 >>>> Tel: 1-888.305.3428 >>>> Fax: 1-248.569.6567 >>>> www.dss-corp.com >>>> www.dispatchimprovement.com >>>> >>>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of Paul Kyzivat >>>> Sent: Thursday, July 26, 2012 6:15 PM >>>> To: siprec@ietf.org >>>> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >>>> >>>> On 7/26/12 5:11 PM, Michael Smith wrote: >>>>> I would think you'd want the SRS, as the recipient of the media, to >>>>> decide whether it wants mixed or unmixed media. And that the SRC >>>>> must support both, and must comply with the SRS's request. And that >>>>> implies that you must have a mechanism for the SRC to tell the SRC >>>>> whether it wants mixed or unmixed media. >>>> >>>> You are going to *require* that the SRC be able to do mixing??? >>>> >>>>> An SRS may receive from many SRCs. What I suggest above allows >>>>> policy to be implemented in one place (the SRS), and forces all >>>>> SRCs to comply with it. >>>> >>>> On the contrary, ISTM that the SRS is a *utility*, and one that >>>> probably has considerable resources. It is providing a service to a >>>> wide range of clients that may vary widely in their capabilities. >>>> It makes much or sense to me that life is made as simple and >>>> flexible as possible for the SRC. >>>> >>>> Leon indicated that some preliminary implementations prefer to >>>> receive the streams unmixed. That is also perhaps easier for the >>>> SRC, at the expense of requiring more bandwidth. Certainly its easier for a "phone" >>>> that might have no mixing capability at all. OTOH there may be >>>> devices that are very bandwidth limited that would prefer to mix >>>> first to conserve the bandwidth. And there may be some devices, such >>>> as a conference focus, for which mixing may be the most convenient >>>> way. And of course there could be an SRC that is a *participant* in >>>> a conference, that has no choice but to accept mixed media from the >>>> focus, and so must pass it along unmixed to the SRS. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Michael Smith >>>>> Chief Technologist >>>>> Ph: 606.877.2788 | Mobile: 606.231.0243 >>>>> >>>>> DSS Corporation / Equature >>>>> 18311 W. Ten Mile Road, Suite 200 >>>>> Southfield, MI - 48075 >>>>> Tel: 1-888.305.3428 >>>>> Fax: 1-248.569.6567 >>>>> www.dss-corp.com >>>>> www.dispatchimprovement.com >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>> Behalf Of Leon Portman >>>>> Sent: Thursday, July 26, 2012 4:59 PM >>>>> To: Paul Kyzivat >>>>> Cc: siprec@ietf.org >>>>> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >>>>> >>>>> Paul Hi >>>>> >>>>> Generic comment: current implementations of SRS support to be >>>>> configured either store unmixed media separately or mixed them on >>>>> SRS side in order to save storage. >>>>> On protocol side: we can define a negotiation of mixing like this: >>>>> If SRC supports sending both mixed and unmixed medias, it can offer >>>>> both in SDP as multiple m-lines and SRS can accept the preferred option. >>>>> Of if it is specific policy on SRC side, SRS still can have option >>>>> to mix if SRC always sends unmixed. >>>>> >>>>> What do you think? >>>>> >>>>> >>>>> Leon >>>>> >>>>> On Jul 26, 2012, at 11:53 PM, Paul Kyzivat >>>>> wrote: >>>>> >>>>>> One small comment on this: >>>>>> >>>>>> Section 3.2.4: >>>>>> >>>>>> When recording this media the two streams may be >>>>>> mixed at the SRC before being transmitted to the SRS or it >>>>>> may be a >>>>>> requirement of the recording server that the media streams are not >>>>>> mixed and are sent to the SRS as two separate streams. >>>>>> >>>>>> Do we really want to say that the SRS can decide that it must have >>>>>> unmixed media??? >>>>>> >>>>>> I don't think so. IMO this should be solely at the discretion of >>>>>> the SRC. >>>>>> >>>>>> If it was up to the SRS, how would it indicate this to the SRC? >>>>>> _______________________________________________ >>>>>> 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 >> _______________________________________________ >> 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 Jul 27 11:16: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 2A03721F855D for ; Fri, 27 Jul 2012 11:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.475 X-Spam-Level: X-Spam-Status: No, score=-10.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNAFHqSoPZHs for ; Fri, 27 Jul 2012 11:16:30 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2174A11E808C for ; Fri, 27 Jul 2012 11:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=17062; q=dns/txt; s=iport; t=1343412990; x=1344622590; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=CnrgwP2Jn6OmMSuTI8qNH0uAtu8d4XFEQ1ewZIrb984=; b=kOS+y5rxs7h8JZVzxfhQ+RyUAAbwvUq2AmADpHyrJEKHor7gHR8Z7J3I 3G5CVgdrGefWXA+ey3NIZ1XGQmrMTtg3QV1uG/QAvp5ttoGtnc1WPHOfa dUHZwIWKKYjnGnfs3e6m2OsLYz8tethab944XLHIY7x2YjK2Bw68RzM+W c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAILaElCtJV2b/2dsb2JhbABCAw65QYEHgiABAQEEAQEBDwEnDx8GFwQCAQgOAwEDAQEBChQJBycLFAMGCAIEARIIEQmHagELmjagWotQCgoMgzOCQWADkWWSCoFmgiY5gVYB X-IronPort-AV: E=Sophos;i="4.77,668,1336348800"; d="scan'208";a="106047395" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 27 Jul 2012 18:16:29 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6RIGTHu022223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Jul 2012 18:16:29 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.205]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0298.004; Fri, 27 Jul 2012 13:16:28 -0500 From: "Charles Eckel (eckelcu)" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] Comments on draft-ietf-siprec-architecture-05 Thread-Index: AQHNa3CumJm0k341mkCM7mdLdTpT5pc8X+6AgAADbgCAABHFAIAADvEAgAAbbICAAEKLgIAAkkSAgAANN4CAAAMhgIAABN+AgAAC6QCAAAWSAP//23mg Date: Fri, 27 Jul 2012 18:16:28 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088280469C0@xmb-aln-x08.cisco.com> References: <5011E4ED.1080101@alum.mit.edu> <05D56509F27CCE4DAF8136C02386880D686CBD5A@exc01.dss.lan> <9B0B6FB9606F4D4AB133C5E9A203B6940559DF494B@SOUEXC01.eu.nice.com> <05D56509F27CCE4DAF8136C02386880D686CC27E@exc01.dss.lan> <5012A93D.5020006@alum.mit.edu> <05D56509F27CCE4DAF8136C02386880D686CC517@exc01.dss.lan> <5012B05A.3030001@alum.mit.edu> In-Reply-To: <5012B05A.3030001@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.122.35] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19066.004 x-tm-as-result: No--74.505500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 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, 27 Jul 2012 18:16:32 -0000 There is already a discussion of the RTP session usage by the SRC planned a= s part of the changes to the protocol draft. I have some slides prepared fo= r this, and section 8.3 of draft-ietf-siprec-protocol-06 (http://tools.ietf= .org/html/draft-ietf-siprec-protocol-06#section-8.3) contains the correspon= ding text. What I proposed there was the SRC has options as to whether to send mixed, = unmixed, or multiplexed streams, and it uses the offer/answer to allow the = SRS in the answer to accept, reject, or indicate support for some subset of= what is offered. I left the need for anything specific in terms of SRS preferences as an ope= n question, partially because my hunch was that SRC and SRS vendors would w= ant to support as many options as possible, and when it came to actual depl= oyments the SRC and SRS would be configured to function as required within = the given deployment. In some cases, a specific SRC or SRS implementation m= ay not be appropriate for a given deployment's requirements, and that is ok= ay. I agree with the statements that an SRC may not being able to un-mix a prev= iously mixed stream, so a preference/configuration for unmixed streams woul= d mean that the SRC should keep the streams as separate as possible. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Friday, July 27, 2012 8:15 AM > To: siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >=20 > On 7/27/12 10:54 AM, Michael Smith wrote: > > Hmmm... perhaps this discussion should be future work? I'm not sure the > group would want to get into something new that is potentially complex at > this point. > > > > I was thinking a mechanism would be fairly straightforward. Perhaps it'= s > not. >=20 > Maybe we will have some time to discuss this as part of the architecture > or protocol discussion. But maybe not - there isn't a lot of time. >=20 > Do the chairs have an opinion on this? >=20 > Thanks, > Paul >=20 > > Michael Smith > > Chief Technologist > > Ph: 606.877.2788 | Mobile: 606.231.0243 > > > > DSS Corporation / Equature > > 18311 W. Ten Mile Road, Suite 200 > > Southfield, MI - 48075 > > Tel: 1-888.305.3428 > > Fax: 1-248.569.6567 > > www.dss-corp.com > > www.dispatchimprovement.com > > > > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > > Sent: Friday, July 27, 2012 10:44 AM > > To: siprec@ietf.org > > Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > > > > On 7/27/12 10:26 AM, Michael Smith wrote: > >> Yeah, I think Paul made the case that a customer can buy an SRC that > supports sending mixed, unmixed or both. But without some requirement, > we don't know what vendors will produce, and you can only buy what's > available. > >> > >> I'm ok with the proposal Paul and Ram made, as long as we're all ok wi= th > the possibility that SRC vendors might offer only mixed, or conversely, o= nly > unmixed. Either could happen, but I suspect the "mixed only" option would > be what we'd end up with - and that's the problem. The server doesn't eve= n > have a choice if that's all the SRC offers. It can only record mixed medi= a. > >> > >> BTW, I looked at the current NENA 08-003 draft. It looks like we dropp= ed > the sentence we initially had about recording unmixed media, perhaps for > the same reasons Paul and Ram have presented. > >> > >> I still would like to have some mechanism for the SRS to make its desi= re > for mixed or unmixed known, and then say that it MAY be used, and the SRC > MAY comply with the request. I think that's better than nothing. > > > > I am agreeable with having some discussion of how the SRS can express > some preferences to the SRC. It doesn't seem to fit well within the > communication framework we have defined so far, so it might require some > significant changes. > > > > One problem is that currently its possible for the SRC to send an INVIT= E to > initiate an RS, with an SDP offer and metadata describing what it wants > recorded initially. The construction of that offer and the metadata alrea= dy > embodies a policy decision about how to do the recording - whether mixed > or unmixed. And at that time there has been > > *no* opportunity for the SRS to indicate its preferences. And I've been= led > to believe its important that things work this way so that a recording ca= n be > established rapidly. > > > > Thanks, > > Paul > > > >> Michael Smith > >> Chief Technologist > >> Ph: 606.877.2788 | Mobile: 606.231.0243 > >> > >> DSS Corporation / Equature > >> 18311 W. Ten Mile Road, Suite 200 > >> Southfield, MI - 48075 > >> Tel: 1-888.305.3428 > >> Fax: 1-248.569.6567 > >> www.dss-corp.com > >> www.dispatchimprovement.com > >> > >> > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Dave Higton > >> Sent: Friday, July 27, 2012 10:16 AM > >> To: siprec@ietf.org > >> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > >> > >> I am accustomed to thinking that the choice to record mixed or unmixed > media is made at time of placing a contract to purchase recording > equipment. That places no requirement to specify at recording time. > >> > >> Is there, therefore, a case for saying that SIPREC does not need to su= pport > such a choice? > >> > >> Dave > >> > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Michael Smith > >> Sent: 27 July 2012 14:28 > >> To: siprec@ietf.org > >> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > >> > >> So Ram proposes: > >> We can have an SRC that does one or more of the following: > >> 1)An SRC MAY support sending unmixed media only > >> 2) An SRC supports sending mixed media only (the case of confere= nce > where SRC is a participant) > >> 3) An SRC supports sending mixed or unmixed media or both > >> > >> I'm curious - do others agree with that position? > >> > >> IMHO, the SRC conference participant case is a non-issue. If an SRC is= a > participant in a Bridge, the "mixed" media coming from the Bridge is a si= ngle > stream from its point of view, and an SRS that wanted unmixed media > would only get whatever streams the SRC had. > >> > >> Now, I would like to see the possibility of the SRS dictating (or at l= east > indicating a desire for) mixed or unmixed media, but if the majority > disagree, I can live with that. > >> > >> I do want to bring this up with the NENA NG9-1-1 recording test > committee I chair. Nine recording companies participate, and I'd like to = see > if that group thinks we should impose additional requirements for an > SRC/SRS used in an NG9-1-1 environment. I don't personally think that > Public Safety needs are different than private sector needs on this issue= , > but it's a good discussion to have now. If there were no mechanism for th= e > SRS to make its mixed/unmixed desire known, we'd have a problem to > solve. Perhaps this group could define such a mechanism without requiring > that it be used? > >> > >> > >> Thanks, > >> > >> Michael Smith > >> Chief Technologist > >> Ph: 606.877.2788 | Mobile: 606.231.0243 > >> > >> DSS Corporation / Equature > >> 18311 W. Ten Mile Road, Suite 200 > >> Southfield, MI - 48075 > >> Tel: 1-888.305.3428 > >> Fax: 1-248.569.6567 > >> www.dss-corp.com > >> www.dispatchimprovement.com > >> > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Ram Mohan R (rmohanr) > >> Sent: Friday, July 27, 2012 12:45 AM > >> To: Paul Kyzivat; siprec@ietf.org > >> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > >> > >>> On 27/07/12 6:16 AM, "Paul Kyzivat" wrote: > >> > >>> On 7/26/12 7:08 PM, Michael Smith wrote: > >>>> Hmmm... What's important is that the SRC supports unmixed streams. > >>>> If it does, the server could mix them, and policy is enforced at > >>>> that point. The drawback to that is that you consume twice the > >>>> bandwidth per CS, even if your policy is to store mixed streams. > >>>> > >>>> Good point about a phone, but they do already mix the two parties > >>>> voices. Mixing is simple, and not processing-intensive, so levying > >>>> that requirement on an SRC isn't onerous, IMHO. > >>>> > >>>> I'd be ok if an SRC didn't support mixing media, and the SRS mixed i= t. > >>>> But I think it's a problem if an SRC mixes media and policy dictates > >>>> that unmixed media be stored - there's no way to un-mix it. > >>> > >>> So what about an SRC connected to a focus of a conference with many > >>> participants. The SRC is only receiving a mixed stream from the > >>> focus, which includes all participants except itself. It can know who > >>> all the participants are (from the conference event package), but it > >>> can't pass them on unmixed. > >>> > >>>> I think requirements might be crafted that an SRS MUST support > >>>> receiving both mixed and unmixed media, and an SRC MUST support > >>>> sending unmixed media, and MAY support sending mixed media. You'd > >>>> still need some mechanism for negotiating mixed/unmixed. > >>> > >>> I'm going to stand by my prior opinion for now. > >>> > >>> As a customer I think you can *prefer* that things work this way. If > >>> you have buying control over the SRC you can specify that. But I > >>> don't think it makes sense to exclude SRCs that work otherwise. > >> > >> > >> I also agree with Paul. We can have an SRC that does one or more of > >> the > >> following: > >> 1)An SRC MAY support sending unmixed media only > >> 2) An SRC supports sending mixed media only (the case of conference > >> where SRC is a participant) > >> 3) An SRC supports sending mixed or unmixed media or both > >> > >> So its better not to restrict and there by exclude some SRCs. > >> > >> Ram > >> > >>> > >>> Thanks, > >>> Paul > >>> > >>>> Michael Smith > >>>> Chief Technologist > >>>> Ph: 606.877.2788 | Mobile: 606.231.0243 > >>>> > >>>> DSS Corporation / Equature > >>>> 18311 W. Ten Mile Road, Suite 200 > >>>> Southfield, MI - 48075 > >>>> Tel: 1-888.305.3428 > >>>> Fax: 1-248.569.6567 > >>>> www.dss-corp.com > >>>> www.dispatchimprovement.com > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>>> Behalf Of Paul Kyzivat > >>>> Sent: Thursday, July 26, 2012 6:15 PM > >>>> To: siprec@ietf.org > >>>> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > >>>> > >>>> On 7/26/12 5:11 PM, Michael Smith wrote: > >>>>> I would think you'd want the SRS, as the recipient of the media, to > >>>>> decide whether it wants mixed or unmixed media. And that the SRC > >>>>> must support both, and must comply with the SRS's request. And that > >>>>> implies that you must have a mechanism for the SRC to tell the SRC > >>>>> whether it wants mixed or unmixed media. > >>>> > >>>> You are going to *require* that the SRC be able to do mixing??? > >>>> > >>>>> An SRS may receive from many SRCs. What I suggest above allows > >>>>> policy to be implemented in one place (the SRS), and forces all > >>>>> SRCs to comply with it. > >>>> > >>>> On the contrary, ISTM that the SRS is a *utility*, and one that > >>>> probably has considerable resources. It is providing a service to a > >>>> wide range of clients that may vary widely in their capabilities. > >>>> It makes much or sense to me that life is made as simple and > >>>> flexible as possible for the SRC. > >>>> > >>>> Leon indicated that some preliminary implementations prefer to > >>>> receive the streams unmixed. That is also perhaps easier for the > >>>> SRC, at the expense of requiring more bandwidth. Certainly its easie= r > for a "phone" > >>>> that might have no mixing capability at all. OTOH there may be > >>>> devices that are very bandwidth limited that would prefer to mix > >>>> first to conserve the bandwidth. And there may be some devices, such > >>>> as a conference focus, for which mixing may be the most convenient > >>>> way. And of course there could be an SRC that is a *participant* in > >>>> a conference, that has no choice but to accept mixed media from the > >>>> focus, and so must pass it along unmixed to the SRS. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>> Michael Smith > >>>>> Chief Technologist > >>>>> Ph: 606.877.2788 | Mobile: 606.231.0243 > >>>>> > >>>>> DSS Corporation / Equature > >>>>> 18311 W. Ten Mile Road, Suite 200 > >>>>> Southfield, MI - 48075 > >>>>> Tel: 1-888.305.3428 > >>>>> Fax: 1-248.569.6567 > >>>>> www.dss-corp.com > >>>>> www.dispatchimprovement.com > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>>>> Behalf Of Leon Portman > >>>>> Sent: Thursday, July 26, 2012 4:59 PM > >>>>> To: Paul Kyzivat > >>>>> Cc: siprec@ietf.org > >>>>> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > >>>>> > >>>>> Paul Hi > >>>>> > >>>>> Generic comment: current implementations of SRS support to be > >>>>> configured either store unmixed media separately or mixed them on > >>>>> SRS side in order to save storage. > >>>>> On protocol side: we can define a negotiation of mixing like this: > >>>>> If SRC supports sending both mixed and unmixed medias, it can offer > >>>>> both in SDP as multiple m-lines and SRS can accept the preferred > option. > >>>>> Of if it is specific policy on SRC side, SRS still can have option > >>>>> to mix if SRC always sends unmixed. > >>>>> > >>>>> What do you think? > >>>>> > >>>>> > >>>>> Leon > >>>>> > >>>>> On Jul 26, 2012, at 11:53 PM, Paul Kyzivat > >>>>> wrote: > >>>>> > >>>>>> One small comment on this: > >>>>>> > >>>>>> Section 3.2.4: > >>>>>> > >>>>>> When recording this media the two streams may be > >>>>>> mixed at the SRC before being transmitted to the SRS or it > >>>>>> may be a > >>>>>> requirement of the recording server that the media streams a= re > not > >>>>>> mixed and are sent to the SRS as two separate streams. > >>>>>> > >>>>>> Do we really want to say that the SRS can decide that it must have > >>>>>> unmixed media??? > >>>>>> > >>>>>> I don't think so. IMO this should be solely at the discretion of > >>>>>> the SRC. > >>>>>> > >>>>>> If it was up to the SRS, how would it indicate this to the SRC? > >>>>>> _______________________________________________ > >>>>>> 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 > >> _______________________________________________ > >> 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 eckelcu@cisco.com Fri Jul 27 12:43: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 1D1E111E80EF for ; Fri, 27 Jul 2012 12:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.181 X-Spam-Level: X-Spam-Status: No, score=-10.181 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, J_CHICKENPOX_110=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 Ocixvn8cYIF9 for ; Fri, 27 Jul 2012 12:43:48 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 268FB11E80F3 for ; Fri, 27 Jul 2012 12:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=5383; q=dns/txt; s=iport; t=1343418228; x=1344627828; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=sE7tJSi92Rd/c/L0fCVSMBSmKDZbcuQVJGwUQ7XonsA=; b=JETik26M38q5pPuemynwmXKkaJ5kc5kLMKhpSbUx0SAPUBF/gQc+ILVl FNO558TF5B3o1JcVt7GVXgMpUw9iFkEkeOGypIvw9uKkDDqceTdKZDLit 8EheCZkPwueMDx5LB68EwsLWz1fG9UC92afNVki+9IQpHZLOBD9/2/Jtn Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAD/uElCtJV2b/2dsb2JhbABFDrlCgQeCIAEBAQMBAQEBDwEnNAQMBwQCAQgOAwQBAQsUCQcnCxQJCAIEAQkJCBqHZQUBC5pCoGAEi1CGFGADo2+BZoImOQ X-IronPort-AV: E=Sophos;i="4.77,668,1336348800"; d="scan'208";a="106120954" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 27 Jul 2012 19:43:47 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6RJhlfv025480 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Jul 2012 19:43:47 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.205]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Fri, 27 Jul 2012 14:43:47 -0500 From: "Charles Eckel (eckelcu)" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] Comments on draft-ietf-siprec-protocol-06 Thread-Index: AQHNa23KGN97zJxb2EedZZXFEhPCa5c9hcnw Date: Fri, 27 Jul 2012 19:43:47 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046AAD@xmb-aln-x08.cisco.com> References: <5011A956.5060700@alum.mit.edu> In-Reply-To: <5011A956.5060700@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.122.35] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19068.001 x-tm-as-result: No--57.783800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Comments on draft-ietf-siprec-protocol-06 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, 27 Jul 2012 19:43:49 -0000 Hi Paul, Thanks for the feedback. Please see inline. > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Thursday, July 26, 2012 1:32 PM > To: siprec@ietf.org > Subject: [siprec] Comments on draft-ietf-siprec-protocol-06 >=20 > Section 8.2.2: >=20 > The SSRCs from the contributing UA SHOULD be conveyed as CSRCs > identifiers within this stream. >=20 > The SSRCs of the contributing UAs that are being mixed will typically > come from independent RTP sessions, and so there could be collisions. > The SRC must cope with this - perhaps by remapping SSRCs. > > Is the following from 8.3.2 intended to deal with this? No, section 8.3.3 is intended to deal with this, specifically: In order to preserve the mapping of media to participant within the CSs in the RS, the SRC SHOULD map each unique CNAME within the CSs to a unique CNAME within the RS. Additionally, the SRC SHOULD map each unique combination of CNAME/SSRC within the CSs to a unique CNAME/ SSRC within the RS. The SRC MUST avoid SSRC collisions, rewriting SSRCs if necessary when used as CSRCs in the RS. In doing to, the SRC acts as an RTP mixer. =20 > In order to preserve the mapping of media to participant within the > CSs in the RS, the SRC SHOULD map each unique combination of CNAME/ > SSRC within the CSs to a unique SSRC within the RS. The CNAMEs used > in the CSs are not preserved within the RS. The SRS relies on the > SIPREC metadata to determine the participants included within each > multiplexed stream. The SRC MUST avoid SSRC collisions, rewriting > SSRCs if necessary. In doing to, the SRC acts as an RTP endpoint. >=20 > But that has its own problems: I agree, I think there are some issues, or at least limitations, associated= with the SRC using SSRC multiplexing. > - Do you really mean a unique SSRC within the *RS*??? Yes, that is what I was proposing as a way to deal with it. > In particular, if the SRC is recording many concurrent independent > CSs, with each CS in a separate RTP session (m-line), must it assign > unique SSRCs across all the RTP sessions? Or only across all the > parts of the same CS? (There is similar language in 8.3.3 without > these problems. Maybe it just needs to be used here too.) If each CS is in a unique m-line and there is no multiplexing of RTP sessio= ns across multiple m-lines, then the SSRCs need only be unique per CS. In my description, I was assuming a single m-line with one or more CSs bein= g multiplexed. >=20 > - If CNAMEs in the CSs aren't preserved in the RS, is there a 1:1 > relation between them? If not, then sync between RTP streams in the CS > won't be possible. If so, I guess it should be mentioned. Exactly, this is why I added the statement: The CNAMEs used in the CSs are not preserved within the RS. The SRS relies on the SIPREC metadata to determine the participants included within each multiplexed stream." =20 > In general, I think we need some discussion of what should happen if RTP > stream multiplexing is being used within a single CS RTP session. ISTM > that there should be a way for the SRC to convey enough info to the SRS > so that it can understand how RTP streams were / weren't multiplexed in > the CS and so reconstruct things properly. (OTOH I don't think the SRC > need be REQUIRED to convey this much info.) I agree, we need more work on this. My underlying goal to convey as much in= SDP, RTP, RTCP as possible and have metadata fill in the gaps. Cheers, Charles =20 > Section 9.1: >=20 > A full metadata snapshot describes all > the recorded streams and all metadata associated with the recording > session. >=20 > This is fine as far as it goes. But I think it would helpful to say a > bit more: >=20 > A full metadata snapshot describes all the sessions, participants, > streams subject to recording at the time of the snapshot, and all > associated metadata. >=20 > (I struggled with this. I hope it isn't too cumbersome.) >=20 > My point is to indicate that this isn't expected to include historical > data, such as sessions that were previously active but that have ended. >=20 > Figure 12: >=20 > It doesn't hurt, but its not necessary to list application/rs-metadata > in the Accept. (Its only *sent*, not *received*.) >=20 > Section 9.2: >=20 > Note that the SRS MAY generate an INVITE > request without an SDP offer but this MUST NOT include a metadata > snapshot request. >=20 > This seems wrong. Fix it by: s/without/with/ >=20 > Section 11.1.1: >=20 > If the a=3Drecordpref attribute is > omitted, then the recording preference would be assumed to be the > recording preference set in a previous SDP offer or answer. >=20 > I believe this to be unwise. One can never be certain that you are > talking to the same entity as before. (There could have been a 3pcc > transfer.) So I think we must assume that the lack of the attribute > means lack of preference. >=20 > Thanks, > Paul >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From prvs=1555156da9=MSmith@dss-corp.com Fri Jul 27 13:05: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 4563121F8575 for ; Fri, 27 Jul 2012 13:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 hOXQw68tyQWU for ; Fri, 27 Jul 2012 13:05:07 -0700 (PDT) Received: from spam.dss-corp.com (spam.dss-corp.com [67.214.118.46]) by ietfa.amsl.com (Postfix) with ESMTP id 72FB921F8568 for ; Fri, 27 Jul 2012 13:05:07 -0700 (PDT) Received: from spam.dss-corp.com (127.0.0.1) by spam.dss-corp.com (MlfMTA v3.2r9) id h2br260171ss for ; Fri, 27 Jul 2012 16:12:17 -0400 (envelope-from ) Received: from exc.dss-corp.com ([192.168.1.5]) by spam.dss-corp.com (SonicWALL 7.2.4.3929) with ESMTP; Fri, 27 Jul 2012 16:12:17 -0400 Received: from EXC01.dss.lan ([fe80::109b:ad4:1a47:2813]) by exc01.dss.lan ([fe80::109b:ad4:1a47:2813%13]) with mapi; Fri, 27 Jul 2012 16:04:47 -0400 From: Michael Smith To: "siprec@ietf.org" Thread-Topic: [siprec] Comments on draft-ietf-siprec-architecture-05 Thread-Index: AQHNa3Czt4ZtpSjdMEe219lQXs2A+5c8TyqA//++Z2CAAFbNAP//xgFggABkW4CAAEKLgIAASdxQgAARLICAAAGlgIAASs6A//++lAAACTzuAAABmdZg Date: Fri, 27 Jul 2012 20:04:48 +0000 Message-ID: <05D56509F27CCE4DAF8136C02386880D686CD992@exc01.dss.lan> References: <5011E4ED.1080101@alum.mit.edu> <05D56509F27CCE4DAF8136C02386880D686CBD5A@exc01.dss.lan> <9B0B6FB9606F4D4AB133C5E9A203B6940559DF494B@SOUEXC01.eu.nice.com> <05D56509F27CCE4DAF8136C02386880D686CC27E@exc01.dss.lan> <5012A93D.5020006@alum.mit.edu> <05D56509F27CCE4DAF8136C02386880D686CC517@exc01.dss.lan> <5012B05A.3030001@alum.mit.edu> In-Reply-To: <5012B05A.3030001@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mlf-Version: 7.2.4.3929 X-Mlf-UniqueId: o201207272012170087120 Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 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, 27 Jul 2012 20:05:09 -0000 Paul, Ram and siprec group members: We discussed this on that NENA recording test committee call I mentioned. T= he consensus there was that this issue is complex enough that it would slow= the siprec group's work down substantially. That group would rather see th= e existing protocol finalized, and see this mixed/unmixed media issue dealt= with in a future version. Your call, but I think we all see the point Paul and Ram were making - that= this will take some thought. Michael Smith Chief Technologist Ph: 606.877.2788 | Mobile: 606.231.0243 DSS Corporation / Equature 18311 W. Ten Mile Road, Suite 200 Southfield, MI - 48075 Tel: 1-888.305.3428 Fax: 1-248.569.6567 www.dss-corp.com www.dispatchimprovement.com -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: Friday, July 27, 2012 11:15 AM To: siprec@ietf.org Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 On 7/27/12 10:54 AM, Michael Smith wrote: > Hmmm... perhaps this discussion should be future work? I'm not sure the g= roup would want to get into something new that is potentially complex at th= is point. > > I was thinking a mechanism would be fairly straightforward. Perhaps it's = not. Maybe we will have some time to discuss this as part of the architecture or= protocol discussion. But maybe not - there isn't a lot of time. Do the chairs have an opinion on this? Thanks, Paul > Michael Smith > Chief Technologist > Ph: 606.877.2788 | Mobile: 606.231.0243 > > DSS Corporation / Equature > 18311 W. Ten Mile Road, Suite 200 > Southfield, MI - 48075 > Tel: 1-888.305.3428 > Fax: 1-248.569.6567 > www.dss-corp.com > www.dispatchimprovement.com > > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Friday, July 27, 2012 10:44 AM > To: siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > > On 7/27/12 10:26 AM, Michael Smith wrote: >> Yeah, I think Paul made the case that a customer can buy an SRC that sup= ports sending mixed, unmixed or both. But without some requirement, we don'= t know what vendors will produce, and you can only buy what's available. >> >> I'm ok with the proposal Paul and Ram made, as long as we're all ok with= the possibility that SRC vendors might offer only mixed, or conversely, on= ly unmixed. Either could happen, but I suspect the "mixed only" option woul= d be what we'd end up with - and that's the problem. The server doesn't eve= n have a choice if that's all the SRC offers. It can only record mixed medi= a. >> >> BTW, I looked at the current NENA 08-003 draft. It looks like we dropped= the sentence we initially had about recording unmixed media, perhaps for t= he same reasons Paul and Ram have presented. >> >> I still would like to have some mechanism for the SRS to make its desire= for mixed or unmixed known, and then say that it MAY be used, and the SRC = MAY comply with the request. I think that's better than nothing. > > I am agreeable with having some discussion of how the SRS can express som= e preferences to the SRC. It doesn't seem to fit well within the communicat= ion framework we have defined so far, so it might require some significant = changes. > > One problem is that currently its possible for the SRC to send an > INVITE to initiate an RS, with an SDP offer and metadata describing > what it wants recorded initially. The construction of that offer and > the metadata already embodies a policy decision about how to do the > recording - whether mixed or unmixed. And at that time there has been > *no* opportunity for the SRS to indicate its preferences. And I've been l= ed to believe its important that things work this way so that a recording c= an be established rapidly. > > Thanks, > Paul > >> Michael Smith >> Chief Technologist >> Ph: 606.877.2788 | Mobile: 606.231.0243 >> >> DSS Corporation / Equature >> 18311 W. Ten Mile Road, Suite 200 >> Southfield, MI - 48075 >> Tel: 1-888.305.3428 >> Fax: 1-248.569.6567 >> www.dss-corp.com >> www.dispatchimprovement.com >> >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Dave Higton >> Sent: Friday, July 27, 2012 10:16 AM >> To: siprec@ietf.org >> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >> >> I am accustomed to thinking that the choice to record mixed or unmixed m= edia is made at time of placing a contract to purchase recording equipment.= That places no requirement to specify at recording time. >> >> Is there, therefore, a case for saying that SIPREC does not need to supp= ort such a choice? >> >> Dave >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Michael Smith >> Sent: 27 July 2012 14:28 >> To: siprec@ietf.org >> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >> >> So Ram proposes: >> We can have an SRC that does one or more of the following: >> 1)An SRC MAY support sending unmixed media only >> 2) An SRC supports sending mixed media only (the case of conferenc= e where SRC is a participant) >> 3) An SRC supports sending mixed or unmixed media or both >> >> I'm curious - do others agree with that position? >> >> IMHO, the SRC conference participant case is a non-issue. If an SRC is a= participant in a Bridge, the "mixed" media coming from the Bridge is a sin= gle stream from its point of view, and an SRS that wanted unmixed media wou= ld only get whatever streams the SRC had. >> >> Now, I would like to see the possibility of the SRS dictating (or at lea= st indicating a desire for) mixed or unmixed media, but if the majority dis= agree, I can live with that. >> >> I do want to bring this up with the NENA NG9-1-1 recording test committe= e I chair. Nine recording companies participate, and I'd like to see if tha= t group thinks we should impose additional requirements for an SRC/SRS used= in an NG9-1-1 environment. I don't personally think that Public Safety nee= ds are different than private sector needs on this issue, but it's a good d= iscussion to have now. If there were no mechanism for the SRS to make its m= ixed/unmixed desire known, we'd have a problem to solve. Perhaps this group= could define such a mechanism without requiring that it be used? >> >> >> Thanks, >> >> Michael Smith >> Chief Technologist >> Ph: 606.877.2788 | Mobile: 606.231.0243 >> >> DSS Corporation / Equature >> 18311 W. Ten Mile Road, Suite 200 >> Southfield, MI - 48075 >> Tel: 1-888.305.3428 >> Fax: 1-248.569.6567 >> www.dss-corp.com >> www.dispatchimprovement.com >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Ram Mohan R (rmohanr) >> Sent: Friday, July 27, 2012 12:45 AM >> To: Paul Kyzivat; siprec@ietf.org >> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >> >>> On 27/07/12 6:16 AM, "Paul Kyzivat" wrote: >> >>> On 7/26/12 7:08 PM, Michael Smith wrote: >>>> Hmmm... What's important is that the SRC supports unmixed streams. >>>> If it does, the server could mix them, and policy is enforced at >>>> that point. The drawback to that is that you consume twice the >>>> bandwidth per CS, even if your policy is to store mixed streams. >>>> >>>> Good point about a phone, but they do already mix the two parties >>>> voices. Mixing is simple, and not processing-intensive, so levying >>>> that requirement on an SRC isn't onerous, IMHO. >>>> >>>> I'd be ok if an SRC didn't support mixing media, and the SRS mixed it. >>>> But I think it's a problem if an SRC mixes media and policy >>>> dictates that unmixed media be stored - there's no way to un-mix it. >>> >>> So what about an SRC connected to a focus of a conference with many >>> participants. The SRC is only receiving a mixed stream from the >>> focus, which includes all participants except itself. It can know >>> who all the participants are (from the conference event package), >>> but it can't pass them on unmixed. >>> >>>> I think requirements might be crafted that an SRS MUST support >>>> receiving both mixed and unmixed media, and an SRC MUST support >>>> sending unmixed media, and MAY support sending mixed media. You'd >>>> still need some mechanism for negotiating mixed/unmixed. >>> >>> I'm going to stand by my prior opinion for now. >>> >>> As a customer I think you can *prefer* that things work this way. If >>> you have buying control over the SRC you can specify that. But I >>> don't think it makes sense to exclude SRCs that work otherwise. >> >> >> I also agree with Paul. We can have an SRC that does one or more of >> the >> following: >> 1)An SRC MAY support sending unmixed media only >> 2) An SRC supports sending mixed media only (the case of conference >> where SRC is a participant) >> 3) An SRC supports sending mixed or unmixed media or both >> >> So its better not to restrict and there by exclude some SRCs. >> >> Ram >> >>> >>> Thanks, >>> Paul >>> >>>> Michael Smith >>>> Chief Technologist >>>> Ph: 606.877.2788 | Mobile: 606.231.0243 >>>> >>>> DSS Corporation / Equature >>>> 18311 W. Ten Mile Road, Suite 200 >>>> Southfield, MI - 48075 >>>> Tel: 1-888.305.3428 >>>> Fax: 1-248.569.6567 >>>> www.dss-corp.com >>>> www.dispatchimprovement.com >>>> >>>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of Paul Kyzivat >>>> Sent: Thursday, July 26, 2012 6:15 PM >>>> To: siprec@ietf.org >>>> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >>>> >>>> On 7/26/12 5:11 PM, Michael Smith wrote: >>>>> I would think you'd want the SRS, as the recipient of the media, >>>>> to decide whether it wants mixed or unmixed media. And that the >>>>> SRC must support both, and must comply with the SRS's request. And >>>>> that implies that you must have a mechanism for the SRC to tell >>>>> the SRC whether it wants mixed or unmixed media. >>>> >>>> You are going to *require* that the SRC be able to do mixing??? >>>> >>>>> An SRS may receive from many SRCs. What I suggest above allows >>>>> policy to be implemented in one place (the SRS), and forces all >>>>> SRCs to comply with it. >>>> >>>> On the contrary, ISTM that the SRS is a *utility*, and one that >>>> probably has considerable resources. It is providing a service to a >>>> wide range of clients that may vary widely in their capabilities. >>>> It makes much or sense to me that life is made as simple and >>>> flexible as possible for the SRC. >>>> >>>> Leon indicated that some preliminary implementations prefer to >>>> receive the streams unmixed. That is also perhaps easier for the >>>> SRC, at the expense of requiring more bandwidth. Certainly its easier = for a "phone" >>>> that might have no mixing capability at all. OTOH there may be >>>> devices that are very bandwidth limited that would prefer to mix >>>> first to conserve the bandwidth. And there may be some devices, >>>> such as a conference focus, for which mixing may be the most >>>> convenient way. And of course there could be an SRC that is a >>>> *participant* in a conference, that has no choice but to accept >>>> mixed media from the focus, and so must pass it along unmixed to the S= RS. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Michael Smith >>>>> Chief Technologist >>>>> Ph: 606.877.2788 | Mobile: 606.231.0243 >>>>> >>>>> DSS Corporation / Equature >>>>> 18311 W. Ten Mile Road, Suite 200 >>>>> Southfield, MI - 48075 >>>>> Tel: 1-888.305.3428 >>>>> Fax: 1-248.569.6567 >>>>> www.dss-corp.com >>>>> www.dispatchimprovement.com >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>> Behalf Of Leon Portman >>>>> Sent: Thursday, July 26, 2012 4:59 PM >>>>> To: Paul Kyzivat >>>>> Cc: siprec@ietf.org >>>>> Subject: Re: [siprec] Comments on >>>>> draft-ietf-siprec-architecture-05 >>>>> >>>>> Paul Hi >>>>> >>>>> Generic comment: current implementations of SRS support to be >>>>> configured either store unmixed media separately or mixed them on >>>>> SRS side in order to save storage. >>>>> On protocol side: we can define a negotiation of mixing like this: >>>>> If SRC supports sending both mixed and unmixed medias, it can >>>>> offer both in SDP as multiple m-lines and SRS can accept the preferre= d option. >>>>> Of if it is specific policy on SRC side, SRS still can have option >>>>> to mix if SRC always sends unmixed. >>>>> >>>>> What do you think? >>>>> >>>>> >>>>> Leon >>>>> >>>>> On Jul 26, 2012, at 11:53 PM, Paul Kyzivat >>>>> wrote: >>>>> >>>>>> One small comment on this: >>>>>> >>>>>> Section 3.2.4: >>>>>> >>>>>> When recording this media the two streams may be >>>>>> mixed at the SRC before being transmitted to the SRS or it >>>>>> may be a >>>>>> requirement of the recording server that the media streams are= not >>>>>> mixed and are sent to the SRS as two separate streams. >>>>>> >>>>>> Do we really want to say that the SRS can decide that it must >>>>>> have unmixed media??? >>>>>> >>>>>> I don't think so. IMO this should be solely at the discretion of >>>>>> the SRC. >>>>>> >>>>>> If it was up to the SRS, how would it indicate this to the SRC? >>>>>> _______________________________________________ >>>>>> 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 >> _______________________________________________ >> 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 Sat Jul 28 15:39: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 6E86421F8666 for ; Sat, 28 Jul 2012 15:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 UmbhEev-Acr5 for ; Sat, 28 Jul 2012 15:39: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 06C3C21F8629 for ; Sat, 28 Jul 2012 15:39:48 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 9477023F04BA; Sun, 29 Jul 2012 00:39:46 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.131]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0309.002; Sun, 29 Jul 2012 00:39:46 +0200 From: "Hutton, Andrew" To: "Richard L. Barnes" , Leon Portman Thread-Topic: [siprec] Security review of draft-ietf-siprec-protocol-05 Thread-Index: AQHNYGzp91y9n9VFF0OSVdz8yrkr05c9stRw Date: Sat, 28 Jul 2012 22:39:45 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF06BA0B@MCHP04MSX.global-ad.net> References: <657A3659-61DB-433A-97F4-593ECD31DB1B@bbn.com> <07465C1D981ABC41A344374066AE1A2C3A9036B0EA@TLVMBX01.nice.com> <8D2C1F31-31A3-4C4F-A6B0-FC493FD718ED@bbn.com> In-Reply-To: <8D2C1F31-31A3-4C4F-A6B0-FC493FD718ED@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Security review of draft-ietf-siprec-protocol-05 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, 28 Jul 2012 22:39:49 -0000 Hi, So if I try to summarize the open issues would the following be correct? 1. We need to tighten up the section on authentication to require mutual au= thentication which could be done via SIP authentication of Mutual TLS Authe= ntication with the later probably preferred. However personally I don't thi= nk we want to require SIPS in the TLS case. 2. Richard suggested that we should specify a key exchange mechanism and su= ggested we might specify DTLS-SRTP with a particular protection profile. As= Leon pointed out so far we have worked on the assumption that we don't nee= d to specify a particular mechanism but maybe we need to tighten up the wor= ding here. Are there any other opinions on this? 3. At present we don't say anything about how the SRC might obtain keys if = it is not terminating media and Richard indicated that we might want to con= sider EKT as a solution. However again this is an area we have deliberately= not specified so is there a reason to do so? Regards Andy > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Richard L. Barnes > Sent: 12 July 2012 21:25 > To: Leon Portman > Cc: siprec@ietf.org > Subject: Re: [siprec] Security review of draft-ietf-siprec-protocol-05 >=20 > Couple of responses inline. >=20 > On Jul 3, 2012, at 2:28 AM, Leon Portman wrote: >=20 > > Richard Hi > > > > Thank you very much for the review. It is very helpful. Please see > below my answers. > > > > Leon > > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Richard L. Barnes > > Sent: Thursday, June 28, 2012 6:58 PM > > To: siprec@ietf.org > > Subject: [siprec] Security review of draft-ietf-siprec-protocol-05 > > > > Dear SIPREC, > > > > At the SIPREC meeting at the last IETF, I volunteered to do a > security review of the SIPREC protocol document. Thanks to the chairs > increasingly persistent reminders, I've finally gotten around to doing > it :) > > > > At one level, my basic question is: How is this better than just > doing a PCAP? I can see the efficiency gains in terms of RTP handling, > but I'm concerned that (1) the security requirements need to be more > tightly specified, and (2) there seems to be quite a bit of information > loss. > > [LeonP] PCAP method (passive sniffing) requires usage of SPAN ports > in order to forward RTP traffic towards recording system. It used to be > popular method of recording but now Enterprises prefer active methods > for following reasons: less configuration overhead, support for remote > recording systems, better security, support for selective recording > etc. I agree on some level of information loss but we do plan to > support different extension of metadata so all additional information > still can be captured. > > > > Starting with the most obvious part: The Security Considerations > needs to be tightened up. This document benefits from the fact that > the SRC and the SRS are logically within the same administrative > domain, so it should be feasible to establish credentials that they use > to authenticate one another. So the document should REQUIRE that the > SRC and the SRS mutually authenticate to one another, either using SIP > authentication or using TLS authentication beneath SIPS. > > [LeonP] Agree > > > > At the media level, is there a reason that you don't specify a keying > mechanism? Why would you not just specify DTLS-SRTP? It may also be > worth noting that because this protocol will tend to be used within an > administrative domain, the need for confidentiality is lower than in > the general Internet; however, there is still a strong need for > authentication. So this document should REQUIRE that implementations > support the SRTP_NULL_HMAC_SHA1_* protection profiles and RECOMMEND > support for others. > > [LeonP] Actually we wanted to support all standard keying mechanisms. > However because SIPREC media session is established in parallel to the > actual communication session, we want to prefer to use keying mechanism > with fastest session negotiation time in order to minimize lost of > recoding (media clipping). DTLS-SRTP is problematic from this point of > view. >=20 > Well, you could buffer to prevent clipping, of course, since this isn't > actually real-time. >=20 > In any case, with TLS session resumption, you can amortize the cost of > TLS negotiation across a long period of time. >=20 >=20 > > Speaking of SRTP, it's not clear whether there's a requirement for > the SRC/SRS to have access to the keys used to protect secure media, in > the case where the SRC is a middlebox, not terminating media. To > support this case, you would need (1) a way to get the key from the > endpoint to the SRC, and (2) a way to get the key from the SRC ot the > SRS. I would suggest looking at EKT / KTR for both of these > [http://tools.ietf.org/html/draft-mcgrew-srtp-ekt-06#section- > 4][http://tools.ietf.org/html/draft-wing-avt-dtls-srtp-key-transport- > 03]. > > [LeonP] Our assumption was that it is out of scope of this work how > SRC will get keys. We used to have text about it and it was removed. We > should discuss it little more. > > > > Finally, it seems like a gap that the SIP signaling information for > the recorded session doesn't get passed off to the SRC. Section 8 of > the current document describes how to pass "metadata", but doesn't > really define what the metadata is. > > [LeonP] We have separate draft for the description of the metadata >=20 > Sorry, missed the reference. > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Sat Jul 28 23:08: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 5E40921F86B4 for ; Sat, 28 Jul 2012 23:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 qM4uAgUg+a7E for ; Sat, 28 Jul 2012 23:08:36 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC7821F86B1 for ; Sat, 28 Jul 2012 23:08:27 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta01.westchester.pa.mail.comcast.net with comcast id g68W1j0010EZKEL5168WUd; Sun, 29 Jul 2012 06:08:30 +0000 Received: from dhcp-40e5.meeting.ietf.org ([IPv6:2001:df8:0:64:81b2:e9a9:6ceb:536f]) by omta01.westchester.pa.mail.comcast.net with comcast id g68d1j00608hHtc3M68eP5; Sun, 29 Jul 2012 06:08:38 +0000 Message-ID: <5014D371.3030802@alum.mit.edu> Date: Sun, 29 Jul 2012 02:08:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <657A3659-61DB-433A-97F4-593ECD31DB1B@bbn.com> <07465C1D981ABC41A344374066AE1A2C3A9036B0EA@TLVMBX01.nice.com> <8D2C1F31-31A3-4C4F-A6B0-FC493FD718ED@bbn.com> <9F33F40F6F2CD847824537F3C4E37DDF06BA0B@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF06BA0B@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Security review of draft-ietf-siprec-protocol-05 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, 29 Jul 2012 06:08:37 -0000 On 7/28/12 6:39 PM, Hutton, Andrew wrote: > Hi, > > So if I try to summarize the open issues would the following be correct? > > 1. We need to tighten up the section on authentication to require mutual authentication which could be done via SIP authentication of Mutual TLS Authentication with the later probably preferred. However personally I don't think we want to require SIPS in the TLS case. I understand why the SRC needs to authenticate the SRS before sending data to it. I *don't* understand why, from a security perspective, its necessary to prevent an SRS from recording unauthenticated SRCs if it wants to. Of course an SRS expends significant resources making recordings, so its likely that it will *want* to authenticate. But that's still a policy decision. Thanks, Paul > 2. Richard suggested that we should specify a key exchange mechanism and suggested we might specify DTLS-SRTP with a particular protection profile. As Leon pointed out so far we have worked on the assumption that we don't need to specify a particular mechanism but maybe we need to tighten up the wording here. Are there any other opinions on this? > > 3. At present we don't say anything about how the SRC might obtain keys if it is not terminating media and Richard indicated that we might want to consider EKT as a solution. However again this is an area we have deliberately not specified so is there a reason to do so? > > Regards > Andy > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Richard L. Barnes >> Sent: 12 July 2012 21:25 >> To: Leon Portman >> Cc: siprec@ietf.org >> Subject: Re: [siprec] Security review of draft-ietf-siprec-protocol-05 >> >> Couple of responses inline. >> >> On Jul 3, 2012, at 2:28 AM, Leon Portman wrote: >> >>> Richard Hi >>> >>> Thank you very much for the review. It is very helpful. Please see >> below my answers. >>> >>> Leon >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Richard L. Barnes >>> Sent: Thursday, June 28, 2012 6:58 PM >>> To: siprec@ietf.org >>> Subject: [siprec] Security review of draft-ietf-siprec-protocol-05 >>> >>> Dear SIPREC, >>> >>> At the SIPREC meeting at the last IETF, I volunteered to do a >> security review of the SIPREC protocol document. Thanks to the chairs >> increasingly persistent reminders, I've finally gotten around to doing >> it :) >>> >>> At one level, my basic question is: How is this better than just >> doing a PCAP? I can see the efficiency gains in terms of RTP handling, >> but I'm concerned that (1) the security requirements need to be more >> tightly specified, and (2) there seems to be quite a bit of information >> loss. >>> [LeonP] PCAP method (passive sniffing) requires usage of SPAN ports >> in order to forward RTP traffic towards recording system. It used to be >> popular method of recording but now Enterprises prefer active methods >> for following reasons: less configuration overhead, support for remote >> recording systems, better security, support for selective recording >> etc. I agree on some level of information loss but we do plan to >> support different extension of metadata so all additional information >> still can be captured. >>> >>> Starting with the most obvious part: The Security Considerations >> needs to be tightened up. This document benefits from the fact that >> the SRC and the SRS are logically within the same administrative >> domain, so it should be feasible to establish credentials that they use >> to authenticate one another. So the document should REQUIRE that the >> SRC and the SRS mutually authenticate to one another, either using SIP >> authentication or using TLS authentication beneath SIPS. >>> [LeonP] Agree >>> >>> At the media level, is there a reason that you don't specify a keying >> mechanism? Why would you not just specify DTLS-SRTP? It may also be >> worth noting that because this protocol will tend to be used within an >> administrative domain, the need for confidentiality is lower than in >> the general Internet; however, there is still a strong need for >> authentication. So this document should REQUIRE that implementations >> support the SRTP_NULL_HMAC_SHA1_* protection profiles and RECOMMEND >> support for others. >>> [LeonP] Actually we wanted to support all standard keying mechanisms. >> However because SIPREC media session is established in parallel to the >> actual communication session, we want to prefer to use keying mechanism >> with fastest session negotiation time in order to minimize lost of >> recoding (media clipping). DTLS-SRTP is problematic from this point of >> view. >> >> Well, you could buffer to prevent clipping, of course, since this isn't >> actually real-time. >> >> In any case, with TLS session resumption, you can amortize the cost of >> TLS negotiation across a long period of time. >> >> >>> Speaking of SRTP, it's not clear whether there's a requirement for >> the SRC/SRS to have access to the keys used to protect secure media, in >> the case where the SRC is a middlebox, not terminating media. To >> support this case, you would need (1) a way to get the key from the >> endpoint to the SRC, and (2) a way to get the key from the SRC ot the >> SRS. I would suggest looking at EKT / KTR for both of these >> [http://tools.ietf.org/html/draft-mcgrew-srtp-ekt-06#section- >> 4][http://tools.ietf.org/html/draft-wing-avt-dtls-srtp-key-transport- >> 03]. >>> [LeonP] Our assumption was that it is out of scope of this work how >> SRC will get keys. We used to have text about it and it was removed. We >> should discuss it little more. >>> >>> Finally, it seems like a gap that the SIP signaling information for >> the recorded session doesn't get passed off to the SRC. Section 8 of >> the current document describes how to pass "metadata", but doesn't >> really define what the metadata is. >>> [LeonP] We have separate draft for the description of the metadata >> >> Sorry, missed the reference. >> _______________________________________________ >> 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 Sun Jul 29 02:16:27 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 E498021F86AD for ; Sun, 29 Jul 2012 02:16:27 -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 KASiELGOrhZI for ; Sun, 29 Jul 2012 02:16:27 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D81A721F86AA for ; Sun, 29 Jul 2012 02:16:26 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4077787vbb.31 for ; Sun, 29 Jul 2012 02:16:26 -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=knXN8MuVcCclRCYSIH9zEvaCR7mLGtqq4kJWPdpoVVo=; b=j0VUQJD029zUAE07Xk433YGeeOl8yZRingOt5YWjlxyl1p1pASxplyffjxA8WSIu7d 1NiVaiV6EV+bQeSU7Sa3ALnPFfpOxKcJfjt8Lijq92QBXp9VYCFq2wlJ6b/QSBLftpGI 4IC91R34P1ovvc+BH4LSXOQd5RihEN/9QPxDGhMOyTIUveNPIHT5Uw1BXxF+k9vwlXxh OpztrS4WEFD3RAqE7Uol4qnHV46lkCtod6pmB9+BSlnj3CMV1KJP5/uBSUTmMrVVo/7S FRL7zBHgHAHB+teClp8AW69qT1H7BQFql511fneuS1lkOS4XcR1YC9AeZ8nQFzOPVutj RkTw== Received: by 10.220.214.205 with SMTP id hb13mr7644506vcb.28.1343553386119; Sun, 29 Jul 2012 02:16:26 -0700 (PDT) Received: from [192.168.102.145] ([69.38.252.85]) by mx.google.com with ESMTPS id ej4sm6635961vdb.0.2012.07.29.02.16.25 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Jul 2012 02:16:25 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Leon Portman In-Reply-To: <5014D371.3030802@alum.mit.edu> Date: Sun, 29 Jul 2012 12:16:24 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0297EEC5-A5C3-4EFB-8947-AADC1B6D69C8@gmail.com> References: <657A3659-61DB-433A-97F4-593ECD31DB1B@bbn.com> <07465C1D981ABC41A344374066AE1A2C3A9036B0EA@TLVMBX01.nice.com> <8D2C1F31-31A3-4C4F-A6B0-FC493FD718ED@bbn.com> <9F33F40F6F2CD847824537F3C4E37DDF06BA0B@MCHP04MSX.global-ad.net> <5014D371.3030802@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1485) Cc: siprec@ietf.org Subject: Re: [siprec] Security review of draft-ietf-siprec-protocol-05 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, 29 Jul 2012 09:16:28 -0000 SRC authentication is also important specially for compliance recording = use case. We can always of course rely on voice print authentication but = still such "fake" SRC can send for example metadata about false calls = claiming for example some financial trader had communication session = with another trader that he is not allowed to talk to (trading chinese = wall compliance rule for example) Leon On Jul 29, 2012, at 9:08 AM, Paul Kyzivat wrote: > On 7/28/12 6:39 PM, Hutton, Andrew wrote: >> Hi, >>=20 >> So if I try to summarize the open issues would the following be = correct? >>=20 >> 1. We need to tighten up the section on authentication to require = mutual authentication which could be done via SIP authentication of = Mutual TLS Authentication with the later probably preferred. However = personally I don't think we want to require SIPS in the TLS case. >=20 > I understand why the SRC needs to authenticate the SRS before sending = data to it. >=20 > I *don't* understand why, from a security perspective, its necessary = to prevent an SRS from recording unauthenticated SRCs if it wants to. Of = course an SRS expends significant resources making recordings, so its = likely that it will *want* to authenticate. But that's still a policy = decision. >=20 > Thanks, > Paul >=20 >> 2. Richard suggested that we should specify a key exchange mechanism = and suggested we might specify DTLS-SRTP with a particular protection = profile. As Leon pointed out so far we have worked on the assumption = that we don't need to specify a particular mechanism but maybe we need = to tighten up the wording here. Are there any other opinions on this? >>=20 >> 3. At present we don't say anything about how the SRC might obtain = keys if it is not terminating media and Richard indicated that we might = want to consider EKT as a solution. However again this is an area we = have deliberately not specified so is there a reason to do so? >>=20 >> Regards >> Andy >>=20 >>=20 >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Richard L. Barnes >>> Sent: 12 July 2012 21:25 >>> To: Leon Portman >>> Cc: siprec@ietf.org >>> Subject: Re: [siprec] Security review of = draft-ietf-siprec-protocol-05 >>>=20 >>> Couple of responses inline. >>>=20 >>> On Jul 3, 2012, at 2:28 AM, Leon Portman wrote: >>>=20 >>>> Richard Hi >>>>=20 >>>> Thank you very much for the review. It is very helpful. Please see >>> below my answers. >>>>=20 >>>> Leon >>>>=20 >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Richard L. Barnes >>>> Sent: Thursday, June 28, 2012 6:58 PM >>>> To: siprec@ietf.org >>>> Subject: [siprec] Security review of draft-ietf-siprec-protocol-05 >>>>=20 >>>> Dear SIPREC, >>>>=20 >>>> At the SIPREC meeting at the last IETF, I volunteered to do a >>> security review of the SIPREC protocol document. Thanks to the = chairs >>> increasingly persistent reminders, I've finally gotten around to = doing >>> it :) >>>>=20 >>>> At one level, my basic question is: How is this better than just >>> doing a PCAP? I can see the efficiency gains in terms of RTP = handling, >>> but I'm concerned that (1) the security requirements need to be more >>> tightly specified, and (2) there seems to be quite a bit of = information >>> loss. >>>> [LeonP] PCAP method (passive sniffing) requires usage of SPAN ports >>> in order to forward RTP traffic towards recording system. It used to = be >>> popular method of recording but now Enterprises prefer active = methods >>> for following reasons: less configuration overhead, support for = remote >>> recording systems, better security, support for selective recording >>> etc. I agree on some level of information loss but we do plan to >>> support different extension of metadata so all additional = information >>> still can be captured. >>>>=20 >>>> Starting with the most obvious part: The Security Considerations >>> needs to be tightened up. This document benefits from the fact that >>> the SRC and the SRS are logically within the same administrative >>> domain, so it should be feasible to establish credentials that they = use >>> to authenticate one another. So the document should REQUIRE that = the >>> SRC and the SRS mutually authenticate to one another, either using = SIP >>> authentication or using TLS authentication beneath SIPS. >>>> [LeonP] Agree >>>>=20 >>>> At the media level, is there a reason that you don't specify a = keying >>> mechanism? Why would you not just specify DTLS-SRTP? It may also = be >>> worth noting that because this protocol will tend to be used within = an >>> administrative domain, the need for confidentiality is lower than in >>> the general Internet; however, there is still a strong need for >>> authentication. So this document should REQUIRE that = implementations >>> support the SRTP_NULL_HMAC_SHA1_* protection profiles and RECOMMEND >>> support for others. >>>> [LeonP] Actually we wanted to support all standard keying = mechanisms. >>> However because SIPREC media session is established in parallel to = the >>> actual communication session, we want to prefer to use keying = mechanism >>> with fastest session negotiation time in order to minimize lost of >>> recoding (media clipping). DTLS-SRTP is problematic from this point = of >>> view. >>>=20 >>> Well, you could buffer to prevent clipping, of course, since this = isn't >>> actually real-time. >>>=20 >>> In any case, with TLS session resumption, you can amortize the cost = of >>> TLS negotiation across a long period of time. >>>=20 >>>=20 >>>> Speaking of SRTP, it's not clear whether there's a requirement for >>> the SRC/SRS to have access to the keys used to protect secure media, = in >>> the case where the SRC is a middlebox, not terminating media. To >>> support this case, you would need (1) a way to get the key from the >>> endpoint to the SRC, and (2) a way to get the key from the SRC ot = the >>> SRS. I would suggest looking at EKT / KTR for both of these >>> [http://tools.ietf.org/html/draft-mcgrew-srtp-ekt-06#section- >>> = 4][http://tools.ietf.org/html/draft-wing-avt-dtls-srtp-key-transport- >>> 03]. >>>> [LeonP] Our assumption was that it is out of scope of this work = how >>> SRC will get keys. We used to have text about it and it was removed. = We >>> should discuss it little more. >>>>=20 >>>> Finally, it seems like a gap that the SIP signaling information for >>> the recorded session doesn't get passed off to the SRC. Section 8 = of >>> the current document describes how to pass "metadata", but doesn't >>> really define what the metadata is. >>>> [LeonP] We have separate draft for the description of the metadata >>>=20 >>> Sorry, missed the reference. >>> _______________________________________________ >>> 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 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Sun Jul 29 07:24: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 D0E6021F86F9 for ; Sun, 29 Jul 2012 07:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 VCzySyDlsjYn for ; Sun, 29 Jul 2012 07:24:52 -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 7B07821F86F6 for ; Sun, 29 Jul 2012 07:24:51 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id D24E71EB8481; Sun, 29 Jul 2012 16:24:49 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.131]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0309.002; Sun, 29 Jul 2012 16:24:49 +0200 From: "Hutton, Andrew" To: Michael Smith , "siprec@ietf.org" Thread-Topic: [siprec] Comments on draft-ietf-siprec-architecture-05 Thread-Index: AQHNa3Czt4ZtpSjdMEe219lQXs2A+5c8TyqA//++Z2CAAFbNAP//xgFggABkW4CAAEKLgIAASdxQgAARLICAAAGlgP//5jmAAABdMAAAALI3AAAKIuQAAFyHlyA= Date: Sun, 29 Jul 2012 14:24:49 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF06BF6B@MCHP04MSX.global-ad.net> References: <5011E4ED.1080101@alum.mit.edu> <05D56509F27CCE4DAF8136C02386880D686CBD5A@exc01.dss.lan> <9B0B6FB9606F4D4AB133C5E9A203B6940559DF494B@SOUEXC01.eu.nice.com> <05D56509F27CCE4DAF8136C02386880D686CC27E@exc01.dss.lan> <5012A93D.5020006@alum.mit.edu> <05D56509F27CCE4DAF8136C02386880D686CC517@exc01.dss.lan> <5012B05A.3030001@alum.mit.edu> <05D56509F27CCE4DAF8136C02386880D686CD992@exc01.dss.lan> In-Reply-To: <05D56509F27CCE4DAF8136C02386880D686CD992@exc01.dss.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 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, 29 Jul 2012 14:24:53 -0000 Hi, How I see it then is the SIPREC architecture does not prevent some type of = capability or preference to be exchanged between the SRS and SRC but we hav= e not so far discussed any such mechanism. I think we don't therefore need = to say anything about this in the architecture draft but could initiate wor= k on a mechanism to achieve this when somebody submits such a draft for con= sideration. If future work is going to be done in SIPREC then we need to make some deci= sion on what this would be before too long. Regards Andy (SIPREC Co-Chair). > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Michael Smith > Sent: 27 July 2012 13:05 > To: siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >=20 > Paul, Ram and siprec group members: >=20 > We discussed this on that NENA recording test committee call I > mentioned. The consensus there was that this issue is complex enough > that it would slow the siprec group's work down substantially. That > group would rather see the existing protocol finalized, and see this > mixed/unmixed media issue dealt with in a future version. >=20 > Your call, but I think we all see the point Paul and Ram were making - > that this will take some thought. >=20 > Michael Smith > Chief Technologist > Ph: 606.877.2788 | Mobile: 606.231.0243 >=20 > DSS Corporation / Equature > 18311 W. Ten Mile Road, Suite 200 > Southfield, MI - 48075 > Tel: 1-888.305.3428 > Fax: 1-248.569.6567 > www.dss-corp.com > www.dispatchimprovement.com >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Friday, July 27, 2012 11:15 AM > To: siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 >=20 > On 7/27/12 10:54 AM, Michael Smith wrote: > > Hmmm... perhaps this discussion should be future work? I'm not sure > the group would want to get into something new that is potentially > complex at this point. > > > > I was thinking a mechanism would be fairly straightforward. Perhaps > it's not. >=20 > Maybe we will have some time to discuss this as part of the > architecture or protocol discussion. But maybe not - there isn't a lot > of time. >=20 > Do the chairs have an opinion on this? >=20 > Thanks, > Paul >=20 > > Michael Smith > > Chief Technologist > > Ph: 606.877.2788 | Mobile: 606.231.0243 > > > > DSS Corporation / Equature > > 18311 W. Ten Mile Road, Suite 200 > > Southfield, MI - 48075 > > Tel: 1-888.305.3428 > > Fax: 1-248.569.6567 > > www.dss-corp.com > > www.dispatchimprovement.com > > > > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > Sent: Friday, July 27, 2012 10:44 AM > > To: siprec@ietf.org > > Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > > > > On 7/27/12 10:26 AM, Michael Smith wrote: > >> Yeah, I think Paul made the case that a customer can buy an SRC that > supports sending mixed, unmixed or both. But without some requirement, > we don't know what vendors will produce, and you can only buy what's > available. > >> > >> I'm ok with the proposal Paul and Ram made, as long as we're all ok > with the possibility that SRC vendors might offer only mixed, or > conversely, only unmixed. Either could happen, but I suspect the "mixed > only" option would be what we'd end up with - and that's the problem. > The server doesn't even have a choice if that's all the SRC offers. It > can only record mixed media. > >> > >> BTW, I looked at the current NENA 08-003 draft. It looks like we > dropped the sentence we initially had about recording unmixed media, > perhaps for the same reasons Paul and Ram have presented. > >> > >> I still would like to have some mechanism for the SRS to make its > desire for mixed or unmixed known, and then say that it MAY be used, > and the SRC MAY comply with the request. I think that's better than > nothing. > > > > I am agreeable with having some discussion of how the SRS can express > some preferences to the SRC. It doesn't seem to fit well within the > communication framework we have defined so far, so it might require > some significant changes. > > > > One problem is that currently its possible for the SRC to send an > > INVITE to initiate an RS, with an SDP offer and metadata describing > > what it wants recorded initially. The construction of that offer and > > the metadata already embodies a policy decision about how to do the > > recording - whether mixed or unmixed. And at that time there has been > > *no* opportunity for the SRS to indicate its preferences. And I've > been led to believe its important that things work this way so that a > recording can be established rapidly. > > > > Thanks, > > Paul > > > >> Michael Smith > >> Chief Technologist > >> Ph: 606.877.2788 | Mobile: 606.231.0243 > >> > >> DSS Corporation / Equature > >> 18311 W. Ten Mile Road, Suite 200 > >> Southfield, MI - 48075 > >> Tel: 1-888.305.3428 > >> Fax: 1-248.569.6567 > >> www.dss-corp.com > >> www.dispatchimprovement.com > >> > >> > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Dave Higton > >> Sent: Friday, July 27, 2012 10:16 AM > >> To: siprec@ietf.org > >> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > >> > >> I am accustomed to thinking that the choice to record mixed or > unmixed media is made at time of placing a contract to purchase > recording equipment. That places no requirement to specify at > recording time. > >> > >> Is there, therefore, a case for saying that SIPREC does not need to > support such a choice? > >> > >> Dave > >> > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Michael Smith > >> Sent: 27 July 2012 14:28 > >> To: siprec@ietf.org > >> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > >> > >> So Ram proposes: > >> We can have an SRC that does one or more of the following: > >> 1)An SRC MAY support sending unmixed media only > >> 2) An SRC supports sending mixed media only (the case of > conference where SRC is a participant) > >> 3) An SRC supports sending mixed or unmixed media or both > >> > >> I'm curious - do others agree with that position? > >> > >> IMHO, the SRC conference participant case is a non-issue. If an SRC > is a participant in a Bridge, the "mixed" media coming from the Bridge > is a single stream from its point of view, and an SRS that wanted > unmixed media would only get whatever streams the SRC had. > >> > >> Now, I would like to see the possibility of the SRS dictating (or at > least indicating a desire for) mixed or unmixed media, but if the > majority disagree, I can live with that. > >> > >> I do want to bring this up with the NENA NG9-1-1 recording test > committee I chair. Nine recording companies participate, and I'd like > to see if that group thinks we should impose additional requirements > for an SRC/SRS used in an NG9-1-1 environment. I don't personally think > that Public Safety needs are different than private sector needs on > this issue, but it's a good discussion to have now. If there were no > mechanism for the SRS to make its mixed/unmixed desire known, we'd have > a problem to solve. Perhaps this group could define such a mechanism > without requiring that it be used? > >> > >> > >> Thanks, > >> > >> Michael Smith > >> Chief Technologist > >> Ph: 606.877.2788 | Mobile: 606.231.0243 > >> > >> DSS Corporation / Equature > >> 18311 W. Ten Mile Road, Suite 200 > >> Southfield, MI - 48075 > >> Tel: 1-888.305.3428 > >> Fax: 1-248.569.6567 > >> www.dss-corp.com > >> www.dispatchimprovement.com > >> > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Ram Mohan R (rmohanr) > >> Sent: Friday, July 27, 2012 12:45 AM > >> To: Paul Kyzivat; siprec@ietf.org > >> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05 > >> > >>> On 27/07/12 6:16 AM, "Paul Kyzivat" wrote: > >> > >>> On 7/26/12 7:08 PM, Michael Smith wrote: > >>>> Hmmm... What's important is that the SRC supports unmixed streams. > >>>> If it does, the server could mix them, and policy is enforced at > >>>> that point. The drawback to that is that you consume twice the > >>>> bandwidth per CS, even if your policy is to store mixed streams. > >>>> > >>>> Good point about a phone, but they do already mix the two parties > >>>> voices. Mixing is simple, and not processing-intensive, so levying > >>>> that requirement on an SRC isn't onerous, IMHO. > >>>> > >>>> I'd be ok if an SRC didn't support mixing media, and the SRS mixed > it. > >>>> But I think it's a problem if an SRC mixes media and policy > >>>> dictates that unmixed media be stored - there's no way to un-mix > it. > >>> > >>> So what about an SRC connected to a focus of a conference with many > >>> participants. The SRC is only receiving a mixed stream from the > >>> focus, which includes all participants except itself. It can know > >>> who all the participants are (from the conference event package), > >>> but it can't pass them on unmixed. > >>> > >>>> I think requirements might be crafted that an SRS MUST support > >>>> receiving both mixed and unmixed media, and an SRC MUST support > >>>> sending unmixed media, and MAY support sending mixed media. You'd > >>>> still need some mechanism for negotiating mixed/unmixed. > >>> > >>> I'm going to stand by my prior opinion for now. > >>> > >>> As a customer I think you can *prefer* that things work this way. > If > >>> you have buying control over the SRC you can specify that. But I > >>> don't think it makes sense to exclude SRCs that work otherwise. > >> > >> > >> I also agree with Paul. We can have an SRC that does one or more of > >> the > >> following: > >> 1)An SRC MAY support sending unmixed media only > >> 2) An SRC supports sending mixed media only (the case of conference > >> where SRC is a participant) > >> 3) An SRC supports sending mixed or unmixed media or both > >> > >> So its better not to restrict and there by exclude some SRCs. > >> > >> Ram > >> > >>> > >>> Thanks, > >>> Paul > >>> > >>>> Michael Smith > >>>> Chief Technologist > >>>> Ph: 606.877.2788 | Mobile: 606.231.0243 > >>>> > >>>> DSS Corporation / Equature > >>>> 18311 W. Ten Mile Road, Suite 200 > >>>> Southfield, MI - 48075 > >>>> Tel: 1-888.305.3428 > >>>> Fax: 1-248.569.6567 > >>>> www.dss-corp.com > >>>> www.dispatchimprovement.com > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>>> Behalf Of Paul Kyzivat > >>>> Sent: Thursday, July 26, 2012 6:15 PM > >>>> To: siprec@ietf.org > >>>> Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture- > 05 > >>>> > >>>> On 7/26/12 5:11 PM, Michael Smith wrote: > >>>>> I would think you'd want the SRS, as the recipient of the media, > >>>>> to decide whether it wants mixed or unmixed media. And that the > >>>>> SRC must support both, and must comply with the SRS's request. > And > >>>>> that implies that you must have a mechanism for the SRC to tell > >>>>> the SRC whether it wants mixed or unmixed media. > >>>> > >>>> You are going to *require* that the SRC be able to do mixing??? > >>>> > >>>>> An SRS may receive from many SRCs. What I suggest above allows > >>>>> policy to be implemented in one place (the SRS), and forces all > >>>>> SRCs to comply with it. > >>>> > >>>> On the contrary, ISTM that the SRS is a *utility*, and one that > >>>> probably has considerable resources. It is providing a service to > a > >>>> wide range of clients that may vary widely in their capabilities. > >>>> It makes much or sense to me that life is made as simple and > >>>> flexible as possible for the SRC. > >>>> > >>>> Leon indicated that some preliminary implementations prefer to > >>>> receive the streams unmixed. That is also perhaps easier for the > >>>> SRC, at the expense of requiring more bandwidth. Certainly its > easier for a "phone" > >>>> that might have no mixing capability at all. OTOH there may be > >>>> devices that are very bandwidth limited that would prefer to mix > >>>> first to conserve the bandwidth. And there may be some devices, > >>>> such as a conference focus, for which mixing may be the most > >>>> convenient way. And of course there could be an SRC that is a > >>>> *participant* in a conference, that has no choice but to accept > >>>> mixed media from the focus, and so must pass it along unmixed to > the SRS. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>> Michael Smith > >>>>> Chief Technologist > >>>>> Ph: 606.877.2788 | Mobile: 606.231.0243 > >>>>> > >>>>> DSS Corporation / Equature > >>>>> 18311 W. Ten Mile Road, Suite 200 > >>>>> Southfield, MI - 48075 > >>>>> Tel: 1-888.305.3428 > >>>>> Fax: 1-248.569.6567 > >>>>> www.dss-corp.com > >>>>> www.dispatchimprovement.com > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>>>> Behalf Of Leon Portman > >>>>> Sent: Thursday, July 26, 2012 4:59 PM > >>>>> To: Paul Kyzivat > >>>>> Cc: siprec@ietf.org > >>>>> Subject: Re: [siprec] Comments on > >>>>> draft-ietf-siprec-architecture-05 > >>>>> > >>>>> Paul Hi > >>>>> > >>>>> Generic comment: current implementations of SRS support to be > >>>>> configured either store unmixed media separately or mixed them > on > >>>>> SRS side in order to save storage. > >>>>> On protocol side: we can define a negotiation of mixing like > this: > >>>>> If SRC supports sending both mixed and unmixed medias, it can > >>>>> offer both in SDP as multiple m-lines and SRS can accept the > preferred option. > >>>>> Of if it is specific policy on SRC side, SRS still can have > option > >>>>> to mix if SRC always sends unmixed. > >>>>> > >>>>> What do you think? > >>>>> > >>>>> > >>>>> Leon > >>>>> > >>>>> On Jul 26, 2012, at 11:53 PM, Paul Kyzivat > >>>>> wrote: > >>>>> > >>>>>> One small comment on this: > >>>>>> > >>>>>> Section 3.2.4: > >>>>>> > >>>>>> When recording this media the two streams may be > >>>>>> mixed at the SRC before being transmitted to the SRS or it > >>>>>> may be a > >>>>>> requirement of the recording server that the media streams > are not > >>>>>> mixed and are sent to the SRS as two separate streams. > >>>>>> > >>>>>> Do we really want to say that the SRS can decide that it must > >>>>>> have unmixed media??? > >>>>>> > >>>>>> I don't think so. IMO this should be solely at the discretion of > >>>>>> the SRC. > >>>>>> > >>>>>> If it was up to the SRS, how would it indicate this to the SRC? > >>>>>> _______________________________________________ > >>>>>> 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 > >> _______________________________________________ > >> 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 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Sun Jul 29 09:01:26 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 4A1C621F85E7 for ; Sun, 29 Jul 2012 09:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 Btt9jpJA+8iA for ; Sun, 29 Jul 2012 09:01:25 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 5097721F8589 for ; Sun, 29 Jul 2012 09:01:25 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta02.westchester.pa.mail.comcast.net with comcast id gFxV1j0020EZKEL51G1UbT; Sun, 29 Jul 2012 16:01:28 +0000 Received: from dhcp-40e5.meeting.ietf.org ([IPv6:2001:df8:0:64:81b2:e9a9:6ceb:536f]) by omta01.westchester.pa.mail.comcast.net with comcast id gG1b1j00608hHtc3MG1bb4; Sun, 29 Jul 2012 16:01:36 +0000 Message-ID: <50155E53.5060903@alum.mit.edu> Date: Sun, 29 Jul 2012 12:01:23 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Leon Portman References: <657A3659-61DB-433A-97F4-593ECD31DB1B@bbn.com> <07465C1D981ABC41A344374066AE1A2C3A9036B0EA@TLVMBX01.nice.com> <8D2C1F31-31A3-4C4F-A6B0-FC493FD718ED@bbn.com> <9F33F40F6F2CD847824537F3C4E37DDF06BA0B@MCHP04MSX.global-ad.net> <5014D371.3030802@alum.mit.edu> <0297EEC5-A5C3-4EFB-8947-AADC1B6D69C8@gmail.com> In-Reply-To: <0297EEC5-A5C3-4EFB-8947-AADC1B6D69C8@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] Security review of draft-ietf-siprec-protocol-05 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, 29 Jul 2012 16:01:26 -0000 On 7/29/12 5:16 AM, Leon Portman wrote: > SRC authentication is also important specially for compliance recording use case. We can always of course rely on voice print authentication but still such "fake" SRC can send for example metadata about false calls claiming for example some financial trader had communication session with another trader that he is not allowed to talk to (trading chinese wall compliance rule for example) Sure, I understand that. But not all recording is done for compliance purposes. I'm only questioning putting a MUST strength requirement on this. I do think SHOULD strength is appropriate. And I do think MUST strength is appropriate for authentication of the SRS. Thanks, Paul > Leon > > > On Jul 29, 2012, at 9:08 AM, Paul Kyzivat wrote: > >> On 7/28/12 6:39 PM, Hutton, Andrew wrote: >>> Hi, >>> >>> So if I try to summarize the open issues would the following be correct? >>> >>> 1. We need to tighten up the section on authentication to require mutual authentication which could be done via SIP authentication of Mutual TLS Authentication with the later probably preferred. However personally I don't think we want to require SIPS in the TLS case. >> >> I understand why the SRC needs to authenticate the SRS before sending data to it. >> >> I *don't* understand why, from a security perspective, its necessary to prevent an SRS from recording unauthenticated SRCs if it wants to. Of course an SRS expends significant resources making recordings, so its likely that it will *want* to authenticate. But that's still a policy decision. >> >> Thanks, >> Paul >> >>> 2. Richard suggested that we should specify a key exchange mechanism and suggested we might specify DTLS-SRTP with a particular protection profile. As Leon pointed out so far we have worked on the assumption that we don't need to specify a particular mechanism but maybe we need to tighten up the wording here. Are there any other opinions on this? >>> >>> 3. At present we don't say anything about how the SRC might obtain keys if it is not terminating media and Richard indicated that we might want to consider EKT as a solution. However again this is an area we have deliberately not specified so is there a reason to do so? >>> >>> Regards >>> Andy >>> >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of Richard L. Barnes >>>> Sent: 12 July 2012 21:25 >>>> To: Leon Portman >>>> Cc: siprec@ietf.org >>>> Subject: Re: [siprec] Security review of draft-ietf-siprec-protocol-05 >>>> >>>> Couple of responses inline. >>>> >>>> On Jul 3, 2012, at 2:28 AM, Leon Portman wrote: >>>> >>>>> Richard Hi >>>>> >>>>> Thank you very much for the review. It is very helpful. Please see >>>> below my answers. >>>>> >>>>> Leon >>>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of Richard L. Barnes >>>>> Sent: Thursday, June 28, 2012 6:58 PM >>>>> To: siprec@ietf.org >>>>> Subject: [siprec] Security review of draft-ietf-siprec-protocol-05 >>>>> >>>>> Dear SIPREC, >>>>> >>>>> At the SIPREC meeting at the last IETF, I volunteered to do a >>>> security review of the SIPREC protocol document. Thanks to the chairs >>>> increasingly persistent reminders, I've finally gotten around to doing >>>> it :) >>>>> >>>>> At one level, my basic question is: How is this better than just >>>> doing a PCAP? I can see the efficiency gains in terms of RTP handling, >>>> but I'm concerned that (1) the security requirements need to be more >>>> tightly specified, and (2) there seems to be quite a bit of information >>>> loss. >>>>> [LeonP] PCAP method (passive sniffing) requires usage of SPAN ports >>>> in order to forward RTP traffic towards recording system. It used to be >>>> popular method of recording but now Enterprises prefer active methods >>>> for following reasons: less configuration overhead, support for remote >>>> recording systems, better security, support for selective recording >>>> etc. I agree on some level of information loss but we do plan to >>>> support different extension of metadata so all additional information >>>> still can be captured. >>>>> >>>>> Starting with the most obvious part: The Security Considerations >>>> needs to be tightened up. This document benefits from the fact that >>>> the SRC and the SRS are logically within the same administrative >>>> domain, so it should be feasible to establish credentials that they use >>>> to authenticate one another. So the document should REQUIRE that the >>>> SRC and the SRS mutually authenticate to one another, either using SIP >>>> authentication or using TLS authentication beneath SIPS. >>>>> [LeonP] Agree >>>>> >>>>> At the media level, is there a reason that you don't specify a keying >>>> mechanism? Why would you not just specify DTLS-SRTP? It may also be >>>> worth noting that because this protocol will tend to be used within an >>>> administrative domain, the need for confidentiality is lower than in >>>> the general Internet; however, there is still a strong need for >>>> authentication. So this document should REQUIRE that implementations >>>> support the SRTP_NULL_HMAC_SHA1_* protection profiles and RECOMMEND >>>> support for others. >>>>> [LeonP] Actually we wanted to support all standard keying mechanisms. >>>> However because SIPREC media session is established in parallel to the >>>> actual communication session, we want to prefer to use keying mechanism >>>> with fastest session negotiation time in order to minimize lost of >>>> recoding (media clipping). DTLS-SRTP is problematic from this point of >>>> view. >>>> >>>> Well, you could buffer to prevent clipping, of course, since this isn't >>>> actually real-time. >>>> >>>> In any case, with TLS session resumption, you can amortize the cost of >>>> TLS negotiation across a long period of time. >>>> >>>> >>>>> Speaking of SRTP, it's not clear whether there's a requirement for >>>> the SRC/SRS to have access to the keys used to protect secure media, in >>>> the case where the SRC is a middlebox, not terminating media. To >>>> support this case, you would need (1) a way to get the key from the >>>> endpoint to the SRC, and (2) a way to get the key from the SRC ot the >>>> SRS. I would suggest looking at EKT / KTR for both of these >>>> [http://tools.ietf.org/html/draft-mcgrew-srtp-ekt-06#section- >>>> 4][http://tools.ietf.org/html/draft-wing-avt-dtls-srtp-key-transport- >>>> 03]. >>>>> [LeonP] Our assumption was that it is out of scope of this work how >>>> SRC will get keys. We used to have text about it and it was removed. We >>>> should discuss it little more. >>>>> >>>>> Finally, it seems like a gap that the SIP signaling information for >>>> the recorded session doesn't get passed off to the SRC. Section 8 of >>>> the current document describes how to pass "metadata", but doesn't >>>> really define what the metadata is. >>>>> [LeonP] We have separate draft for the description of the metadata >>>> >>>> Sorry, missed the reference. >>>> _______________________________________________ >>>> 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 Jul 30 10: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 4D9D511E80A3 for ; Mon, 30 Jul 2012 10:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 EwC92xCnagiC for ; Mon, 30 Jul 2012 10:14:04 -0700 (PDT) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with ESMTP id 76AA411E80A4 for ; Mon, 30 Jul 2012 10:14:03 -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 DSNKUBbA2iL0M0tFMCRHmmh1uT0r97TDZkFR@postini.com; Mon, 30 Jul 2012 10:14:03 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.309.2; Mon, 30 Jul 2012 13:14:01 -0400 Received: from INBA-MAIL02.sonusnet.com ([fe80::f8d4:7090:f632:bbbc]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.02.0309.002; Mon, 30 Jul 2012 22:43:58 +0530 From: "Ravindran, Parthasarathi" To: "siprec@ietf.org" Thread-Topic: "==" padding in Metadata URN UUID [wasFW: [Insipid] Session-ID construction choices] Thread-Index: AQHNbna04x1bx7sjBEGis99fSfy2DA== Date: Mon, 30 Jul 2012 17:13:58 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C2BD13C1C@inba-mail02.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] "==" padding in Metadata URN UUID [wasFW: [Insipid] Session-ID construction choices] 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, 30 Jul 2012 17:14:05 -0000 Hi all, Metadata uses based 64 encoding of URN UUID. There is a discussion in INSIP= ID WG to optimize "=3D=3D" padding occurs due to base 64 URN UUID. I attach= ed Paul's snip of the below mail thread. If we go with base64, I agree that we don't need to preserve the trailing "= =3D=3D". I'm fine with the optimization as it reduces 2 bytes in each URN UUID of me= tadata XML element. I'm interested in hearing WG opinion about this optimiz= ation. Thanks Partha -----Original Message----- From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Paul Kyzivat Sent: Thursday, July 26, 2012 8:30 PM To: Paul E. Jones Cc: 'James Polk'; insipid@ietf.org Subject: Re: [Insipid] Session-ID construction choices On 7/24/12 10:51 PM, Paul E. Jones wrote: > Paul, > > Following up on this thread, as I did not see an outcome. I think=20 > this message might be the last in the series on this topic. > > I think your proposal is along the lines of what we originally=20 > proposed. As I understand, there is a desire to always include both A and= B's halves. > That's fine, so long as devices understand they might change from one=20 > message to the next. > > So given these two abbreviated UUIDs: > > UUID 1: 0xaeffa652 > UUID 2: 0xbe11afc8 > > We would have: > > Session-ID: 0xaeffa652be11afc8 > > If we agree to encode it in hex and agree on the size (a 16 octet=20 > UUID), that means this will always be a 64-byte hex string and there=20 > is no need to put a :. We could also base64 encode the 64 octet=20 > binary value, which would encode in 44 octets (shaving off 20 octets). =20 > Do we want to go for reduced size or more readable hex string? I don't have a strong feeling about hex vs. base64. But I think it would be good to have a separator (I'm not attached to ":" -= that is just an example.) I realize it isn't logically necessary as long a= s the halves are fixed length. But its not very friendly, and I think it is= worth "wasting" *1* byte on. If we go with base64, I agree that we don't need to preserve the trailing "= =3D=3D". > As for putting the entire Session-ID into messages, there are many=20 > situations where the Session-ID will be wrong. Let me give you just=20 > one example. > > Syntax: > A =3D=3D B means A is in a call with B > > A =3D=3D B&& A =3D=3D C (A in call with B; A has a separate call with C= .) > > && B =3D=3D D (B has a separate call with D) > > A& B are talking. A puts B on hold. > A starts talking to C. > Meanwhile B puts A on hold and talks to D. > > A performs some action to join B and C, while at the same time B=20 > performs some action to join D and C > > Assuming a PBX does this magic, we might have some INVITE messages=20 > going down the wire like this: > > + INVITE ----> C (so C can talk to B) (Session-ID: B || C) > PBX1 ---| > + INVITE ----> B (so B can talk to C) (Session-ID: B || C) > > And we have > > + INVITE ----> A (so A can talk to D) (Session-ID: A || D) > PBX2 ---| > + INVITE ----> D (so D can talk to A) (Session-ID: A || D) I can't fully follow the above. My problem is that I don't know where PBX1 and PBX2 fit into the topology of A,B,C,D. So I'm not going to specula= te much. > Now, these messages are passing on the wire at the same time. So that=20 > message from PBX1 heading toward B is actually now heading toward D. ??? > So, what D receives is Session-ID "B || C". D thought the Session-ID=20 > was A > || D. It will be confused. Perhaps PBX2 can massage the Session-ID,=20 > || but > it's not supposed to do that. We really don't want intermediaries to=20 > touch it. Can you please map out the full topology, and a lot more of the call flow y= ou have in mind. (Including REFERs, or some other indication of how the PBX= s are being instructed what to do.) (There are a million ways this could be= done.) > To avoid these kinds of race conditions, adding complexity to try to=20 > straighten it out, etc., I very much prefer to have only the=20 > Session-ID-UUID header that contains only the UUID of the sender of=20 > the message. If we did that, the endpoints in the above scenario=20 > would not be confused and the correct Session-ID could be noted in logs. I'm not ready to leap to this conclusion until I understand the cases bette= r. Thanks, Paul K > Paul > >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On=20 >> Behalf Of Paul Kyzivat >> Sent: Wednesday, July 11, 2012 7:38 PM >> To: James Polk >> Cc: insipid@ietf.org >> Subject: Re: [Insipid] Session-ID construction choices >> >> On 7/11/12 6:23 PM, James Polk wrote: >> ... >>>>> Option#1 - attach a prefix (e.g., From: and To:) to each half >> ... >>>>> We have a proposal going forward: insert the From:/To: tags from=20 >>>>> Option #1. >>>>> >>>>> Does anyone have a technical reason why this wouldn't work? >>>> >>>> Do you mean to assign From and To once, and then keep it fixed for=20 >>>> the duration of the dialog? ISTM that From and To are not well=20 >>>> defined in all cases. >>>> >>>> For instance, consider a BTBUA that sets up a session by inviting=20 >>>> both endpoints. Which is From and which is To? IIUC, the reason for=20 >>>> labeling this way is so that someone observing a session id in a=20 >>>> message can tell which half corresponds to which end. Using From=20 >>>> and To won't satisfy that unless those tags are reassigned for each >> request. >>>> (This is a special case of a conference focus, which you already=20 >>>> call out as an exception.) >>> >>> The desire is to have the same half in the same position throughout=20 >>> the transaction or dialog (whichever it is). I believe in the case=20 >>> of a B2BUA initiating or originating the transaction or dialog on=20 >>> behalf of other endpoint UAs, the B2BUA would pick which Session-ID=20 >>> is the From and which is the To. IOW - we don't make it a=20 >>> requirement on an implementation that Alice is always inserting her=20 >>> half in first, and Bob in as the second half. If the B2BUA is=20 >>> sending an INVITE to both Alice and Bob, then that's 2 separate=20 >>> Session-IDs because it's two different dialogs, even if a 3rd party=20 >>> isn't part (i.e., listening) of the media flow. This would be a hub=20 >>> and 2 spokes in which the hub doesn't listen or interact with the media= of the 2 UAs. >>> >>> We could also have text that says for this scenario, that an INVITE=20 >>> normally inserts the From half of the Session-ID, but that in this=20 >>> scenario it can insert the To: half and the invitee inserts the To half= . >>> >>> >>>> Identifying which end is which is easy for any single transaction, >>> >>> agreed >>> >>>> but hard if you want to use the same identifiers in every message. >>>> The endpoints can easily figure this out, because they should know=20 >>>> their half, and the half that isn't theirs is the other end's. But=20 >>>> its not simple for middleboxes. >>> >>> remember that each half is a UUID or GUID, which will always be a=20 >>> unique value through space and time. >>> >>> >>>> The solution that is used for dialog ids is to use To and From, but=20 >>>> they must be reassigned depending on the direction of the message.=20 >>>> We could do the same for session id, but only if they are remapped=20 >>>> based on the direction of the request. >>> >>> I guess I'm no getting why the halves need to switch places yet=20 >>> depending on whether it's in a request or response. Or are you=20 >>> saying that for one complete transaction they are in a certain=20 >>> order, but in a related transaction(s) they are possibly in the=20 >>> reverse order - depending on who sent the message? >> >> When a message is sent in the reverse direction from the dialog=20 >> establishing message, the From URI and To URI are reversed, as well=20 >> as the From and To tags. If the session id still has its halves=20 >> tagged consistent with the from and to of the dialog establishing=20 >> request, then you will get confused about which half goes with which end= . >> >> There is no problem for servers that keep state and remember the=20 >> values for each end. For them we don't need to tag the halves at all. >> >> There is also no problem for those who don't *care* which end is which. >> And there may be a lot of those. >> >> This tagging is only there for those who don't keep state yet need to=20 >> know. Maybe there aren't any of those, in which case we can stop=20 >> worrying about it. >> >> I guess an example that might matter is something analyzing logs, and=20 >> doesn't have a complete set of logs available to it - in particular=20 >> it doesn't have a log of the initial signaling that set up the=20 >> session, so it can't figure out which half-id belongs to which end. >> >> Then it sees a change - it sees a message where half of the id=20 >> matches prior things, but the other half doesn't - is new. From this=20 >> it can perhaps infer that there was a transfer. And in that case it=20 >> will want to know which end remains and which was replaced. But it=20 >> can't figure that out from which half of the id changed without=20 >> knowing the mapping from half to end. >> >> But I will be the first to say that this case is somewhat implausible. >> In practice there will be lots of stuff in the messages being=20 >> analyzed that should support figuring this out. Perhaps this just=20 >> isn't a good example, and there is another that is better. But I=20 >> don't know a better one. Anybody else? (I think Paul J was the one=20 >> who raised this concern, so maybe he has an example.) >> >> If we can't find a plausible reason why we need to do this mapping,=20 >> then I propose that we just not bother. In that case I think=20 >> representation >> #3 is attractive. It provides for the easiest comparison between id=20 >> values >> - a single string comparison is sufficient. And its among the most=20 >> compact representations. I'd recommend: >> >> session-id: SmallestHalf:BiggestHalf >> >> Or just >> >> session-id: FirstHalf >> >> before the half for the far end has been assigned. >> >> Thanks, >> Paul >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > > _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From leon.portman@gmail.com Mon Jul 30 10:15:01 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 20AC421F855D for ; Mon, 30 Jul 2012 10:15:01 -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 qRPYzeynnMYI for ; Mon, 30 Jul 2012 10:15:00 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B479211E809B for ; Mon, 30 Jul 2012 10:14:58 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so10099655pbc.31 for ; Mon, 30 Jul 2012 10:14:58 -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=r6Qg/hvG8mk6PRsw79jMf+/W+EnHv2kYGwk3/1lr+N8=; b=BeEgevxipNPhC598sS9Anev2xKTp7nP9pEabY/Ntv/mgGxgE6TqPAUDt7bEDqM4sSi +/8nc2W7GHng2kAoxLikpHInQnET6L+AY2mljfZBmtN1eWvDeGcwbbbOBeqHTPeh+7Dk 8gXyI/eS+1VabesXSSX4PhNPklsV9OgQureqBqmg2QWs26WJBgkvNVlLdhc7LMqqsUBD 2XaTKZwJ8iDIgdpYQJwHF1DFHvIpCeqcOMezu2NfRpTzo4njkWnveVwV0roV+EjPxLXG c/dOjsCUOhWOKHTmai60upoxBPdd5BFkjYcnlD98wjQBxXUo5CPXyhW4m/a3PXuY6IeM er4g== Received: by 10.68.192.73 with SMTP id he9mr37183964pbc.68.1343668498385; Mon, 30 Jul 2012 10:14:58 -0700 (PDT) Received: from dhcp-1431.meeting.ietf.org (dhcp-1431.meeting.ietf.org. [130.129.20.49]) by mx.google.com with ESMTPS id pe8sm8260559pbc.76.2012.07.30.10.14.57 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Jul 2012 10:14:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Leon Portman In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C2BD13C1C@inba-mail02.sonusnet.com> Date: Mon, 30 Jul 2012 20:14:56 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <39BC3072-7704-4EFA-8B63-51F95215C71E@gmail.com> References: <387F9047F55E8C42850AD6B3A7A03C6C2BD13C1C@inba-mail02.sonusnet.com> To: "Ravindran, Parthasarathi" X-Mailer: Apple Mail (2.1485) Cc: "siprec@ietf.org" Subject: Re: [siprec] "==" padding in Metadata URN UUID [wasFW: [Insipid] Session-ID construction choices] 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, 30 Jul 2012 17:15:01 -0000 I am OK Leon On Jul 30, 2012, at 8:13 PM, "Ravindran, Parthasarathi" = wrote: > Hi all, >=20 > Metadata uses based 64 encoding of URN UUID. There is a discussion in = INSIPID WG to optimize "=3D=3D" padding occurs due to base 64 URN UUID. = I attached Paul's snip of the below mail thread. >=20 > > If we go with base64, I agree that we don't need to preserve the = trailing "=3D=3D". > >=20 > I'm fine with the optimization as it reduces 2 bytes in each URN UUID = of metadata XML element. I'm interested in hearing WG opinion about this = optimization. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On = Behalf Of Paul Kyzivat > Sent: Thursday, July 26, 2012 8:30 PM > To: Paul E. Jones > Cc: 'James Polk'; insipid@ietf.org > Subject: Re: [Insipid] Session-ID construction choices >=20 > On 7/24/12 10:51 PM, Paul E. Jones wrote: >> Paul, >>=20 >> Following up on this thread, as I did not see an outcome. I think=20 >> this message might be the last in the series on this topic. >>=20 >> I think your proposal is along the lines of what we originally=20 >> proposed. As I understand, there is a desire to always include both A = and B's halves. >> That's fine, so long as devices understand they might change from one=20= >> message to the next. >>=20 >> So given these two abbreviated UUIDs: >>=20 >> UUID 1: 0xaeffa652 >> UUID 2: 0xbe11afc8 >>=20 >> We would have: >>=20 >> Session-ID: 0xaeffa652be11afc8 >>=20 >> If we agree to encode it in hex and agree on the size (a 16 octet=20 >> UUID), that means this will always be a 64-byte hex string and there=20= >> is no need to put a :. We could also base64 encode the 64 octet=20 >> binary value, which would encode in 44 octets (shaving off 20 = octets). =20 >> Do we want to go for reduced size or more readable hex string? >=20 > I don't have a strong feeling about hex vs. base64. > But I think it would be good to have a separator (I'm not attached to = ":" - that is just an example.) I realize it isn't logically necessary = as long as the halves are fixed length. But its not very friendly, and I = think it is worth "wasting" *1* byte on. >=20 > If we go with base64, I agree that we don't need to preserve the = trailing "=3D=3D". >=20 >> As for putting the entire Session-ID into messages, there are many=20 >> situations where the Session-ID will be wrong. Let me give you just=20= >> one example. >>=20 >> Syntax: >> A =3D=3D B means A is in a call with B >>=20 >> A =3D=3D B&& A =3D=3D C (A in call with B; A has a separate call = with C.) >>=20 >> && B =3D=3D D (B has a separate call with D) >>=20 >> A& B are talking. A puts B on hold. >> A starts talking to C. >> Meanwhile B puts A on hold and talks to D. >>=20 >> A performs some action to join B and C, while at the same time B=20 >> performs some action to join D and C >>=20 >> Assuming a PBX does this magic, we might have some INVITE messages=20 >> going down the wire like this: >>=20 >> + INVITE ----> C (so C can talk to B) (Session-ID: B || C) >> PBX1 ---| >> + INVITE ----> B (so B can talk to C) (Session-ID: B || C) >>=20 >> And we have >>=20 >> + INVITE ----> A (so A can talk to D) (Session-ID: A || D) >> PBX2 ---| >> + INVITE ----> D (so D can talk to A) (Session-ID: A || D) >=20 > I can't fully follow the above. My problem is that I don't know where > PBX1 and PBX2 fit into the topology of A,B,C,D. So I'm not going to = speculate much. >=20 >> Now, these messages are passing on the wire at the same time. So = that=20 >> message from PBX1 heading toward B is actually now heading toward D. >=20 > ??? >=20 >> So, what D receives is Session-ID "B || C". D thought the Session-ID=20= >> was A >> || D. It will be confused. Perhaps PBX2 can massage the Session-ID,=20= >> || but >> it's not supposed to do that. We really don't want intermediaries to=20= >> touch it. >=20 > Can you please map out the full topology, and a lot more of the call = flow you have in mind. (Including REFERs, or some other indication of = how the PBXs are being instructed what to do.) (There are a million ways = this could be done.) >=20 >> To avoid these kinds of race conditions, adding complexity to try to=20= >> straighten it out, etc., I very much prefer to have only the=20 >> Session-ID-UUID header that contains only the UUID of the sender of=20= >> the message. If we did that, the endpoints in the above scenario=20 >> would not be confused and the correct Session-ID could be noted in = logs. >=20 > I'm not ready to leap to this conclusion until I understand the cases = better. >=20 > Thanks, > Paul K >=20 >> Paul >>=20 >>> -----Original Message----- >>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On=20= >>> Behalf Of Paul Kyzivat >>> Sent: Wednesday, July 11, 2012 7:38 PM >>> To: James Polk >>> Cc: insipid@ietf.org >>> Subject: Re: [Insipid] Session-ID construction choices >>>=20 >>> On 7/11/12 6:23 PM, James Polk wrote: >>> ... >>>>>> Option#1 - attach a prefix (e.g., From: and To:) to each half >>> ... >>>>>> We have a proposal going forward: insert the From:/To: tags from=20= >>>>>> Option #1. >>>>>>=20 >>>>>> Does anyone have a technical reason why this wouldn't work? >>>>>=20 >>>>> Do you mean to assign =46rom and To once, and then keep it fixed = for=20 >>>>> the duration of the dialog? ISTM that =46rom and To are not well=20= >>>>> defined in all cases. >>>>>=20 >>>>> For instance, consider a BTBUA that sets up a session by inviting=20= >>>>> both endpoints. Which is =46rom and which is To? IIUC, the reason = for=20 >>>>> labeling this way is so that someone observing a session id in a=20= >>>>> message can tell which half corresponds to which end. Using =46rom=20= >>>>> and To won't satisfy that unless those tags are reassigned for = each >>> request. >>>>> (This is a special case of a conference focus, which you already=20= >>>>> call out as an exception.) >>>>=20 >>>> The desire is to have the same half in the same position throughout=20= >>>> the transaction or dialog (whichever it is). I believe in the case=20= >>>> of a B2BUA initiating or originating the transaction or dialog on=20= >>>> behalf of other endpoint UAs, the B2BUA would pick which Session-ID=20= >>>> is the =46rom and which is the To. IOW - we don't make it a=20 >>>> requirement on an implementation that Alice is always inserting her=20= >>>> half in first, and Bob in as the second half. If the B2BUA is=20 >>>> sending an INVITE to both Alice and Bob, then that's 2 separate=20 >>>> Session-IDs because it's two different dialogs, even if a 3rd party=20= >>>> isn't part (i.e., listening) of the media flow. This would be a hub=20= >>>> and 2 spokes in which the hub doesn't listen or interact with the = media of the 2 UAs. >>>>=20 >>>> We could also have text that says for this scenario, that an INVITE=20= >>>> normally inserts the =46rom half of the Session-ID, but that in = this=20 >>>> scenario it can insert the To: half and the invitee inserts the To = half. >>>>=20 >>>>=20 >>>>> Identifying which end is which is easy for any single transaction, >>>>=20 >>>> agreed >>>>=20 >>>>> but hard if you want to use the same identifiers in every message. >>>>> The endpoints can easily figure this out, because they should know=20= >>>>> their half, and the half that isn't theirs is the other end's. But=20= >>>>> its not simple for middleboxes. >>>>=20 >>>> remember that each half is a UUID or GUID, which will always be a=20= >>>> unique value through space and time. >>>>=20 >>>>=20 >>>>> The solution that is used for dialog ids is to use To and From, = but=20 >>>>> they must be reassigned depending on the direction of the message.=20= >>>>> We could do the same for session id, but only if they are remapped=20= >>>>> based on the direction of the request. >>>>=20 >>>> I guess I'm no getting why the halves need to switch places yet=20 >>>> depending on whether it's in a request or response. Or are you=20 >>>> saying that for one complete transaction they are in a certain=20 >>>> order, but in a related transaction(s) they are possibly in the=20 >>>> reverse order - depending on who sent the message? >>>=20 >>> When a message is sent in the reverse direction from the dialog=20 >>> establishing message, the =46rom URI and To URI are reversed, as = well=20 >>> as the =46rom and To tags. If the session id still has its halves=20= >>> tagged consistent with the from and to of the dialog establishing=20 >>> request, then you will get confused about which half goes with which = end. >>>=20 >>> There is no problem for servers that keep state and remember the=20 >>> values for each end. For them we don't need to tag the halves at = all. >>>=20 >>> There is also no problem for those who don't *care* which end is = which. >>> And there may be a lot of those. >>>=20 >>> This tagging is only there for those who don't keep state yet need = to=20 >>> know. Maybe there aren't any of those, in which case we can stop=20 >>> worrying about it. >>>=20 >>> I guess an example that might matter is something analyzing logs, = and=20 >>> doesn't have a complete set of logs available to it - in particular=20= >>> it doesn't have a log of the initial signaling that set up the=20 >>> session, so it can't figure out which half-id belongs to which end. >>>=20 >>> Then it sees a change - it sees a message where half of the id=20 >>> matches prior things, but the other half doesn't - is new. =46rom = this=20 >>> it can perhaps infer that there was a transfer. And in that case it=20= >>> will want to know which end remains and which was replaced. But it=20= >>> can't figure that out from which half of the id changed without=20 >>> knowing the mapping from half to end. >>>=20 >>> But I will be the first to say that this case is somewhat = implausible. >>> In practice there will be lots of stuff in the messages being=20 >>> analyzed that should support figuring this out. Perhaps this just=20 >>> isn't a good example, and there is another that is better. But I=20 >>> don't know a better one. Anybody else? (I think Paul J was the one=20= >>> who raised this concern, so maybe he has an example.) >>>=20 >>> If we can't find a plausible reason why we need to do this mapping,=20= >>> then I propose that we just not bother. In that case I think=20 >>> representation >>> #3 is attractive. It provides for the easiest comparison between id=20= >>> values >>> - a single string comparison is sufficient. And its among the most=20= >>> compact representations. I'd recommend: >>>=20 >>> session-id: SmallestHalf:BiggestHalf >>>=20 >>> Or just >>>=20 >>> session-id: FirstHalf >>>=20 >>> before the half for the far end has been assigned. >>>=20 >>> Thanks, >>> Paul >>> _______________________________________________ >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >>=20 >>=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From Henry.Lum@genesyslab.com Mon Jul 30 12:28: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 A38A011E81BE for ; Mon, 30 Jul 2012 12:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, J_CHICKENPOX_110=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 ijPji0GARPwy for ; Mon, 30 Jul 2012 12:28:21 -0700 (PDT) Received: from relay-out2.dc.genesyslab.com (relay-out2.dc.genesyslab.com [198.49.180.221]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3D511E808D for ; Mon, 30 Jul 2012 12:28:20 -0700 (PDT) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id q6UJSJvO026177; Mon, 30 Jul 2012 12:28:19 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jul 2012 12:28:19 -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: Mon, 30 Jul 2012 12:28:17 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF7408D8FBF8@NAHALD.us.int.genesyslab.com> In-Reply-To: <5011A956.5060700@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Comments on draft-ietf-siprec-protocol-06 Thread-Index: Ac1rbcYYpdv4KrKDRxixjX2e1XCL+QDG6k+A References: <5011A956.5060700@alum.mit.edu> From: "Henry Lum" To: "Paul Kyzivat" , X-OriginalArrivalTime: 30 Jul 2012 19:28:19.0713 (UTC) FILETIME=[79D41710:01CD6E89] Subject: Re: [siprec] Comments on draft-ietf-siprec-protocol-06 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, 30 Jul 2012 19:28:21 -0000 Hi Paul, Please see inline. Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Paul Kyzivat > Sent: July-26-12 4:32 PM > To: siprec@ietf.org > Subject: [siprec] Comments on draft-ietf-siprec-protocol-06 >=20 > Section 8.2.2: >=20 > The SSRCs from the contributing UA SHOULD be conveyed as CSRCs > identifiers within this stream. >=20 > The SSRCs of the contributing UAs that are being mixed will typically=20 > come from independent RTP sessions, and so there could be collisions. > The SRC must cope with this - perhaps by remapping SSRCs. >=20 > Is the following from 8.3.2 intended to deal with this? >=20 > In order to preserve the mapping of media to participant within the > CSs in the RS, the SRC SHOULD map each unique combination of CNAME/ > SSRC within the CSs to a unique SSRC within the RS. The CNAMEs used > in the CSs are not preserved within the RS. The SRS relies on the > SIPREC metadata to determine the participants included within each > multiplexed stream. The SRC MUST avoid SSRC collisions, rewriting > SSRCs if necessary. In doing to, the SRC acts as an RTP endpoint. >=20 > But that has its own problems: >=20 > - Do you really mean a unique SSRC within the *RS*??? > In particular, if the SRC is recording many concurrent independent > CSs, with each CS in a separate RTP session (m-line), must it assign > unique SSRCs across all the RTP sessions? Or only across all the > parts of the same CS? (There is similar language in 8.3.3 without > these problems. Maybe it just needs to be used here too.) >=20 > - If CNAMEs in the CSs aren't preserved in the RS, is there a 1:1 > relation between them? If not, then sync between RTP streams in the CS > won't be possible. If so, I guess it should be mentioned. >=20 > In general, I think we need some discussion of what should happen if=20 > RTP stream multiplexing is being used within a single CS RTP session.=20 > ISTM that there should be a way for the SRC to convey enough info to=20 > the SRS so that it can understand how RTP streams were / weren't=20 > multiplexed in the CS and so reconstruct things properly. (OTOH I=20 > don't think the SRC need be REQUIRED to convey this much info.) >=20 > Section 9.1: >=20 > A full metadata snapshot describes all > the recorded streams and all metadata associated with the recording > session. >=20 > This is fine as far as it goes. But I think it would helpful to say a=20 > bit more: >=20 > A full metadata snapshot describes all the sessions, participants, > streams subject to recording at the time of the snapshot, and all > associated metadata. >=20 > (I struggled with this. I hope it isn't too cumbersome.) >=20 > My point is to indicate that this isn't expected to include historical > data, such as sessions that were previously active but that have ended. >=20 [Henry] I agree clarity is important here; will update the wording to reflect this point.=20 > Figure 12: >=20 > It doesn't hurt, but its not necessary to list application/rs-metadata > in the Accept. (Its only *sent*, not *received*.) >=20 [Henry] Thanks for catching this. > Section 9.2: >=20 > Note that the SRS MAY generate an INVITE > request without an SDP offer but this MUST NOT include a metadata > snapshot request. >=20 > This seems wrong. Fix it by: s/without/with/ >=20 [Henry] Oops! Thanks for catching this! > Section 11.1.1: >=20 > If the a=3Drecordpref attribute is > omitted, then the recording preference would be assumed to be the > recording preference set in a previous SDP offer or answer. >=20 > I believe this to be unwise. One can never be certain that you are=20 > talking to the same entity as before. (There could have been a 3pcc > transfer.) So I think we must assume that the lack of the attribute=20 > means lack of preference. [Henry] I too had a bit of trouble when I was writing this statement to define the behaviour for omission. It makes sense that in the case of 3pcc then we cannot guarantee that the preference can be remembered. I am okay to treat omission as no preference stated. >=20 > Thanks, > Paul >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Mon Jul 30 20:12: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 7A46811E80EC for ; Mon, 30 Jul 2012 20:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 Cdy8BFH22v3m for ; Mon, 30 Jul 2012 20:12:12 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 09FB611E80E2 for ; Mon, 30 Jul 2012 20:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=11790; q=dns/txt; s=iport; t=1343704332; x=1344913932; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=VsXuw6c/dgXrTZtBUxgd6YrxNP0UjFwZ94xq1nomFs4=; b=Gw3sYJbJRX0wkP5Ot86pzsysuw25LercBi/HWK8vGIp5WdYgCDB2DO1y yECL9B6DM9ISOP/O4U4EzX9+Ha4Q0Ry77NEvNF1Dm6U2cA+MoamrlYIIu G9ENX9UT8VZ/cGXAiSUgHIvTT2Z/oicnYbn49RklBZ9IQpNm8HoZGoRhP c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAK1MF1CtJV2d/2dsb2JhbABFuWKBB4IgAQEBAwEBAQEPARQTLgYLBQcGAQgRBAEBAR4JKAYLFAkIAgQKBAUbB4dcAwYGC5p/lnANiUoEimZoGoZvA5N0gVSLCoMdgWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,681,1336348800"; d="scan'208";a="106631402" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 31 Jul 2012 03:12:11 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q6V3CBFO011242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Jul 2012 03:12:11 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.49]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Mon, 30 Jul 2012 22:10:03 -0500 From: "Ram Mohan R (rmohanr)" To: Leon Portman , "Ravindran, Parthasarathi" Thread-Topic: [siprec] "==" padding in Metadata URN UUID [wasFW: [Insipid] Session-ID construction choices] Thread-Index: AQHNbspGXISmzzH9KEusTHlX/PtcmQ== Date: Tue, 31 Jul 2012 03:12:10 +0000 Message-ID: In-Reply-To: <39BC3072-7704-4EFA-8B63-51F95215C71E@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [173.39.68.104] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19074.001 x-tm-as-result: No--60.577400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <8D8CB0857B587E4B97E895A30E3E9B01@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] "==" padding in Metadata URN UUID [wasFW: [Insipid] Session-ID construction choices] 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, 31 Jul 2012 03:12:13 -0000 I am Ok too. Ram > On 30/07/12 10:44 PM, "Leon Portman" wrote: >I am OK > >Leon >On Jul 30, 2012, at 8:13 PM, "Ravindran, Parthasarathi" > wrote: > >> Hi all, >>=20 >> Metadata uses based 64 encoding of URN UUID. There is a discussion in >>INSIPID WG to optimize "=3D=3D" padding occurs due to base 64 URN UUID. I >>attached Paul's snip of the below mail thread. >>=20 >> >> If we go with base64, I agree that we don't need to preserve the >>trailing "=3D=3D". >> >>=20 >> I'm fine with the optimization as it reduces 2 bytes in each URN UUID >>of metadata XML element. I'm interested in hearing WG opinion about this >>optimization. >>=20 >> Thanks >> Partha >>=20 >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>Behalf Of Paul Kyzivat >> Sent: Thursday, July 26, 2012 8:30 PM >> To: Paul E. Jones >> Cc: 'James Polk'; insipid@ietf.org >> Subject: Re: [Insipid] Session-ID construction choices >>=20 >> On 7/24/12 10:51 PM, Paul E. Jones wrote: >>> Paul, >>>=20 >>> Following up on this thread, as I did not see an outcome. I think >>> this message might be the last in the series on this topic. >>>=20 >>> I think your proposal is along the lines of what we originally >>> proposed. As I understand, there is a desire to always include both A >>>and B's halves. >>> That's fine, so long as devices understand they might change from one >>> message to the next. >>>=20 >>> So given these two abbreviated UUIDs: >>>=20 >>> UUID 1: 0xaeffa652 >>> UUID 2: 0xbe11afc8 >>>=20 >>> We would have: >>>=20 >>> Session-ID: 0xaeffa652be11afc8 >>>=20 >>> If we agree to encode it in hex and agree on the size (a 16 octet >>> UUID), that means this will always be a 64-byte hex string and there >>> is no need to put a :. We could also base64 encode the 64 octet >>> binary value, which would encode in 44 octets (shaving off 20 octets). >>>=20 >>> Do we want to go for reduced size or more readable hex string? >>=20 >> I don't have a strong feeling about hex vs. base64. >> But I think it would be good to have a separator (I'm not attached to >>":" - that is just an example.) I realize it isn't logically necessary >>as long as the halves are fixed length. But its not very friendly, and I >>think it is worth "wasting" *1* byte on. >>=20 >> If we go with base64, I agree that we don't need to preserve the >>trailing "=3D=3D". >>=20 >>> As for putting the entire Session-ID into messages, there are many >>> situations where the Session-ID will be wrong. Let me give you just >>> one example. >>>=20 >>> Syntax: >>> A =3D=3D B means A is in a call with B >>>=20 >>> A =3D=3D B&& A =3D=3D C (A in call with B; A has a separate call with= C.) >>>=20 >>> && B =3D=3D D (B has a separate call with D) >>>=20 >>> A& B are talking. A puts B on hold. >>> A starts talking to C. >>> Meanwhile B puts A on hold and talks to D. >>>=20 >>> A performs some action to join B and C, while at the same time B >>> performs some action to join D and C >>>=20 >>> Assuming a PBX does this magic, we might have some INVITE messages >>> going down the wire like this: >>>=20 >>> + INVITE ----> C (so C can talk to B) (Session-ID: B || C) >>> PBX1 ---| >>> + INVITE ----> B (so B can talk to C) (Session-ID: B || C) >>>=20 >>> And we have >>>=20 >>> + INVITE ----> A (so A can talk to D) (Session-ID: A || D) >>> PBX2 ---| >>> + INVITE ----> D (so D can talk to A) (Session-ID: A || D) >>=20 >> I can't fully follow the above. My problem is that I don't know where >> PBX1 and PBX2 fit into the topology of A,B,C,D. So I'm not going to >>speculate much. >>=20 >>> Now, these messages are passing on the wire at the same time. So that >>> message from PBX1 heading toward B is actually now heading toward D. >>=20 >> ??? >>=20 >>> So, what D receives is Session-ID "B || C". D thought the Session-ID >>> was A >>> || D. It will be confused. Perhaps PBX2 can massage the Session-ID, >>> || but >>> it's not supposed to do that. We really don't want intermediaries to >>> touch it. >>=20 >> Can you please map out the full topology, and a lot more of the call >>flow you have in mind. (Including REFERs, or some other indication of >>how the PBXs are being instructed what to do.) (There are a million ways >>this could be done.) >>=20 >>> To avoid these kinds of race conditions, adding complexity to try to >>> straighten it out, etc., I very much prefer to have only the >>> Session-ID-UUID header that contains only the UUID of the sender of >>> the message. If we did that, the endpoints in the above scenario >>> would not be confused and the correct Session-ID could be noted in >>>logs. >>=20 >> I'm not ready to leap to this conclusion until I understand the cases >>better. >>=20 >> Thanks, >> Paul K >>=20 >>> Paul >>>=20 >>>> -----Original Message----- >>>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>>> Behalf Of Paul Kyzivat >>>> Sent: Wednesday, July 11, 2012 7:38 PM >>>> To: James Polk >>>> Cc: insipid@ietf.org >>>> Subject: Re: [Insipid] Session-ID construction choices >>>>=20 >>>> On 7/11/12 6:23 PM, James Polk wrote: >>>> ... >>>>>>> Option#1 - attach a prefix (e.g., From: and To:) to each half >>>> ... >>>>>>> We have a proposal going forward: insert the From:/To: tags from >>>>>>> Option #1. >>>>>>>=20 >>>>>>> Does anyone have a technical reason why this wouldn't work? >>>>>>=20 >>>>>> Do you mean to assign From and To once, and then keep it fixed for >>>>>> the duration of the dialog? ISTM that From and To are not well >>>>>> defined in all cases. >>>>>>=20 >>>>>> For instance, consider a BTBUA that sets up a session by inviting >>>>>> both endpoints. Which is From and which is To? IIUC, the reason for >>>>>> labeling this way is so that someone observing a session id in a >>>>>> message can tell which half corresponds to which end. Using From >>>>>> and To won't satisfy that unless those tags are reassigned for each >>>> request. >>>>>> (This is a special case of a conference focus, which you already >>>>>> call out as an exception.) >>>>>=20 >>>>> The desire is to have the same half in the same position throughout >>>>> the transaction or dialog (whichever it is). I believe in the case >>>>> of a B2BUA initiating or originating the transaction or dialog on >>>>> behalf of other endpoint UAs, the B2BUA would pick which Session-ID >>>>> is the From and which is the To. IOW - we don't make it a >>>>> requirement on an implementation that Alice is always inserting her >>>>> half in first, and Bob in as the second half. If the B2BUA is >>>>> sending an INVITE to both Alice and Bob, then that's 2 separate >>>>> Session-IDs because it's two different dialogs, even if a 3rd party >>>>> isn't part (i.e., listening) of the media flow. This would be a hub >>>>> and 2 spokes in which the hub doesn't listen or interact with the >>>>>media of the 2 UAs. >>>>>=20 >>>>> We could also have text that says for this scenario, that an INVITE >>>>> normally inserts the From half of the Session-ID, but that in this >>>>> scenario it can insert the To: half and the invitee inserts the To >>>>>half. >>>>>=20 >>>>>=20 >>>>>> Identifying which end is which is easy for any single transaction, >>>>>=20 >>>>> agreed >>>>>=20 >>>>>> but hard if you want to use the same identifiers in every message. >>>>>> The endpoints can easily figure this out, because they should know >>>>>> their half, and the half that isn't theirs is the other end's. But >>>>>> its not simple for middleboxes. >>>>>=20 >>>>> remember that each half is a UUID or GUID, which will always be a >>>>> unique value through space and time. >>>>>=20 >>>>>=20 >>>>>> The solution that is used for dialog ids is to use To and From, but >>>>>> they must be reassigned depending on the direction of the message. >>>>>> We could do the same for session id, but only if they are remapped >>>>>> based on the direction of the request. >>>>>=20 >>>>> I guess I'm no getting why the halves need to switch places yet >>>>> depending on whether it's in a request or response. Or are you >>>>> saying that for one complete transaction they are in a certain >>>>> order, but in a related transaction(s) they are possibly in the >>>>> reverse order - depending on who sent the message? >>>>=20 >>>> When a message is sent in the reverse direction from the dialog >>>> establishing message, the From URI and To URI are reversed, as well >>>> as the From and To tags. If the session id still has its halves >>>> tagged consistent with the from and to of the dialog establishing >>>> request, then you will get confused about which half goes with which >>>>end. >>>>=20 >>>> There is no problem for servers that keep state and remember the >>>> values for each end. For them we don't need to tag the halves at all. >>>>=20 >>>> There is also no problem for those who don't *care* which end is >>>>which. >>>> And there may be a lot of those. >>>>=20 >>>> This tagging is only there for those who don't keep state yet need to >>>> know. Maybe there aren't any of those, in which case we can stop >>>> worrying about it. >>>>=20 >>>> I guess an example that might matter is something analyzing logs, and >>>> doesn't have a complete set of logs available to it - in particular >>>> it doesn't have a log of the initial signaling that set up the >>>> session, so it can't figure out which half-id belongs to which end. >>>>=20 >>>> Then it sees a change - it sees a message where half of the id >>>> matches prior things, but the other half doesn't - is new. From this >>>> it can perhaps infer that there was a transfer. And in that case it >>>> will want to know which end remains and which was replaced. But it >>>> can't figure that out from which half of the id changed without >>>> knowing the mapping from half to end. >>>>=20 >>>> But I will be the first to say that this case is somewhat implausible. >>>> In practice there will be lots of stuff in the messages being >>>> analyzed that should support figuring this out. Perhaps this just >>>> isn't a good example, and there is another that is better. But I >>>> don't know a better one. Anybody else? (I think Paul J was the one >>>> who raised this concern, so maybe he has an example.) >>>>=20 >>>> If we can't find a plausible reason why we need to do this mapping, >>>> then I propose that we just not bother. In that case I think >>>> representation >>>> #3 is attractive. It provides for the easiest comparison between id >>>> values >>>> - a single string comparison is sufficient. And its among the most >>>> compact representations. I'd recommend: >>>>=20 >>>> session-id: SmallestHalf:BiggestHalf >>>>=20 >>>> Or just >>>>=20 >>>> session-id: FirstHalf >>>>=20 >>>> before the half for the far end has been assigned. >>>>=20 >>>> Thanks, >>>> Paul >>>> _______________________________________________ >>>> insipid mailing list >>>> insipid@ietf.org >>>> https://www.ietf.org/mailman/listinfo/insipid >>>=20 >>>=20 >>=20 >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid >> _______________________________________________ >> 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 Jul 30 22:27:42 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 9EB5521F8549 for ; Mon, 30 Jul 2012 22:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 EeUiDI6b6qrw for ; Mon, 30 Jul 2012 22:27:41 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBB421F8532 for ; Mon, 30 Jul 2012 22:27:41 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta02.westchester.pa.mail.comcast.net with comcast id gtRQ1j0020QuhwU51tTjLW; Tue, 31 Jul 2012 05:27:43 +0000 Received: from dhcp-40e5.meeting.ietf.org ([IPv6:2001:df8:0:64:cdc6:6051:fcdb:1db6]) by omta02.westchester.pa.mail.comcast.net with comcast id gtTU1j0091a3fix3NtTVSq; Tue, 31 Jul 2012 05:27:30 +0000 Message-ID: <50176CC9.80701@alum.mit.edu> Date: Mon, 30 Jul 2012 22:27:37 -0700 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] "==" padding in Metadata URN UUID [wasFW: [Insipid] Session-ID construction choices] 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, 31 Jul 2012 05:27:42 -0000 I don't have strong feelings either way. Just understand that omitting the "==" locks us in to 64 bit values. That doesn't seem to be a big constraint, since the spec we're referencing for the value calls for 64 bits. Thanks, Paul On 7/30/12 8:12 PM, Ram Mohan R (rmohanr) wrote: > I am Ok too. > > Ram > >> On 30/07/12 10:44 PM, "Leon Portman" wrote: > >> I am OK >> >> Leon >> On Jul 30, 2012, at 8:13 PM, "Ravindran, Parthasarathi" >> wrote: >> >>> Hi all, >>> >>> Metadata uses based 64 encoding of URN UUID. There is a discussion in >>> INSIPID WG to optimize "==" padding occurs due to base 64 URN UUID. I >>> attached Paul's snip of the below mail thread. >>> >>> >>> If we go with base64, I agree that we don't need to preserve the >>> trailing "==". >>> >>> >>> I'm fine with the optimization as it reduces 2 bytes in each URN UUID >>> of metadata XML element. I'm interested in hearing WG opinion about this >>> optimization. >>> >>> Thanks >>> Partha >>> >>> -----Original Message----- >>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: Thursday, July 26, 2012 8:30 PM >>> To: Paul E. Jones >>> Cc: 'James Polk'; insipid@ietf.org >>> Subject: Re: [Insipid] Session-ID construction choices >>> >>> On 7/24/12 10:51 PM, Paul E. Jones wrote: >>>> Paul, >>>> >>>> Following up on this thread, as I did not see an outcome. I think >>>> this message might be the last in the series on this topic. >>>> >>>> I think your proposal is along the lines of what we originally >>>> proposed. As I understand, there is a desire to always include both A >>>> and B's halves. >>>> That's fine, so long as devices understand they might change from one >>>> message to the next. >>>> >>>> So given these two abbreviated UUIDs: >>>> >>>> UUID 1: 0xaeffa652 >>>> UUID 2: 0xbe11afc8 >>>> >>>> We would have: >>>> >>>> Session-ID: 0xaeffa652be11afc8 >>>> >>>> If we agree to encode it in hex and agree on the size (a 16 octet >>>> UUID), that means this will always be a 64-byte hex string and there >>>> is no need to put a :. We could also base64 encode the 64 octet >>>> binary value, which would encode in 44 octets (shaving off 20 octets). >>>> >>>> Do we want to go for reduced size or more readable hex string? >>> >>> I don't have a strong feeling about hex vs. base64. >>> But I think it would be good to have a separator (I'm not attached to >>> ":" - that is just an example.) I realize it isn't logically necessary >>> as long as the halves are fixed length. But its not very friendly, and I >>> think it is worth "wasting" *1* byte on. >>> >>> If we go with base64, I agree that we don't need to preserve the >>> trailing "==". >>> >>>> As for putting the entire Session-ID into messages, there are many >>>> situations where the Session-ID will be wrong. Let me give you just >>>> one example. >>>> >>>> Syntax: >>>> A == B means A is in a call with B >>>> >>>> A == B&& A == C (A in call with B; A has a separate call with C.) >>>> >>>> && B == D (B has a separate call with D) >>>> >>>> A& B are talking. A puts B on hold. >>>> A starts talking to C. >>>> Meanwhile B puts A on hold and talks to D. >>>> >>>> A performs some action to join B and C, while at the same time B >>>> performs some action to join D and C >>>> >>>> Assuming a PBX does this magic, we might have some INVITE messages >>>> going down the wire like this: >>>> >>>> + INVITE ----> C (so C can talk to B) (Session-ID: B || C) >>>> PBX1 ---| >>>> + INVITE ----> B (so B can talk to C) (Session-ID: B || C) >>>> >>>> And we have >>>> >>>> + INVITE ----> A (so A can talk to D) (Session-ID: A || D) >>>> PBX2 ---| >>>> + INVITE ----> D (so D can talk to A) (Session-ID: A || D) >>> >>> I can't fully follow the above. My problem is that I don't know where >>> PBX1 and PBX2 fit into the topology of A,B,C,D. So I'm not going to >>> speculate much. >>> >>>> Now, these messages are passing on the wire at the same time. So that >>>> message from PBX1 heading toward B is actually now heading toward D. >>> >>> ??? >>> >>>> So, what D receives is Session-ID "B || C". D thought the Session-ID >>>> was A >>>> || D. It will be confused. Perhaps PBX2 can massage the Session-ID, >>>> || but >>>> it's not supposed to do that. We really don't want intermediaries to >>>> touch it. >>> >>> Can you please map out the full topology, and a lot more of the call >>> flow you have in mind. (Including REFERs, or some other indication of >>> how the PBXs are being instructed what to do.) (There are a million ways >>> this could be done.) >>> >>>> To avoid these kinds of race conditions, adding complexity to try to >>>> straighten it out, etc., I very much prefer to have only the >>>> Session-ID-UUID header that contains only the UUID of the sender of >>>> the message. If we did that, the endpoints in the above scenario >>>> would not be confused and the correct Session-ID could be noted in >>>> logs. >>> >>> I'm not ready to leap to this conclusion until I understand the cases >>> better. >>> >>> Thanks, >>> Paul K >>> >>>> Paul >>>> >>>>> -----Original Message----- >>>>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>>>> Behalf Of Paul Kyzivat >>>>> Sent: Wednesday, July 11, 2012 7:38 PM >>>>> To: James Polk >>>>> Cc: insipid@ietf.org >>>>> Subject: Re: [Insipid] Session-ID construction choices >>>>> >>>>> On 7/11/12 6:23 PM, James Polk wrote: >>>>> ... >>>>>>>> Option#1 - attach a prefix (e.g., From: and To:) to each half >>>>> ... >>>>>>>> We have a proposal going forward: insert the From:/To: tags from >>>>>>>> Option #1. >>>>>>>> >>>>>>>> Does anyone have a technical reason why this wouldn't work? >>>>>>> >>>>>>> Do you mean to assign From and To once, and then keep it fixed for >>>>>>> the duration of the dialog? ISTM that From and To are not well >>>>>>> defined in all cases. >>>>>>> >>>>>>> For instance, consider a BTBUA that sets up a session by inviting >>>>>>> both endpoints. Which is From and which is To? IIUC, the reason for >>>>>>> labeling this way is so that someone observing a session id in a >>>>>>> message can tell which half corresponds to which end. Using From >>>>>>> and To won't satisfy that unless those tags are reassigned for each >>>>> request. >>>>>>> (This is a special case of a conference focus, which you already >>>>>>> call out as an exception.) >>>>>> >>>>>> The desire is to have the same half in the same position throughout >>>>>> the transaction or dialog (whichever it is). I believe in the case >>>>>> of a B2BUA initiating or originating the transaction or dialog on >>>>>> behalf of other endpoint UAs, the B2BUA would pick which Session-ID >>>>>> is the From and which is the To. IOW - we don't make it a >>>>>> requirement on an implementation that Alice is always inserting her >>>>>> half in first, and Bob in as the second half. If the B2BUA is >>>>>> sending an INVITE to both Alice and Bob, then that's 2 separate >>>>>> Session-IDs because it's two different dialogs, even if a 3rd party >>>>>> isn't part (i.e., listening) of the media flow. This would be a hub >>>>>> and 2 spokes in which the hub doesn't listen or interact with the >>>>>> media of the 2 UAs. >>>>>> >>>>>> We could also have text that says for this scenario, that an INVITE >>>>>> normally inserts the From half of the Session-ID, but that in this >>>>>> scenario it can insert the To: half and the invitee inserts the To >>>>>> half. >>>>>> >>>>>> >>>>>>> Identifying which end is which is easy for any single transaction, >>>>>> >>>>>> agreed >>>>>> >>>>>>> but hard if you want to use the same identifiers in every message. >>>>>>> The endpoints can easily figure this out, because they should know >>>>>>> their half, and the half that isn't theirs is the other end's. But >>>>>>> its not simple for middleboxes. >>>>>> >>>>>> remember that each half is a UUID or GUID, which will always be a >>>>>> unique value through space and time. >>>>>> >>>>>> >>>>>>> The solution that is used for dialog ids is to use To and From, but >>>>>>> they must be reassigned depending on the direction of the message. >>>>>>> We could do the same for session id, but only if they are remapped >>>>>>> based on the direction of the request. >>>>>> >>>>>> I guess I'm no getting why the halves need to switch places yet >>>>>> depending on whether it's in a request or response. Or are you >>>>>> saying that for one complete transaction they are in a certain >>>>>> order, but in a related transaction(s) they are possibly in the >>>>>> reverse order - depending on who sent the message? >>>>> >>>>> When a message is sent in the reverse direction from the dialog >>>>> establishing message, the From URI and To URI are reversed, as well >>>>> as the From and To tags. If the session id still has its halves >>>>> tagged consistent with the from and to of the dialog establishing >>>>> request, then you will get confused about which half goes with which >>>>> end. >>>>> >>>>> There is no problem for servers that keep state and remember the >>>>> values for each end. For them we don't need to tag the halves at all. >>>>> >>>>> There is also no problem for those who don't *care* which end is >>>>> which. >>>>> And there may be a lot of those. >>>>> >>>>> This tagging is only there for those who don't keep state yet need to >>>>> know. Maybe there aren't any of those, in which case we can stop >>>>> worrying about it. >>>>> >>>>> I guess an example that might matter is something analyzing logs, and >>>>> doesn't have a complete set of logs available to it - in particular >>>>> it doesn't have a log of the initial signaling that set up the >>>>> session, so it can't figure out which half-id belongs to which end. >>>>> >>>>> Then it sees a change - it sees a message where half of the id >>>>> matches prior things, but the other half doesn't - is new. From this >>>>> it can perhaps infer that there was a transfer. And in that case it >>>>> will want to know which end remains and which was replaced. But it >>>>> can't figure that out from which half of the id changed without >>>>> knowing the mapping from half to end. >>>>> >>>>> But I will be the first to say that this case is somewhat implausible. >>>>> In practice there will be lots of stuff in the messages being >>>>> analyzed that should support figuring this out. Perhaps this just >>>>> isn't a good example, and there is another that is better. But I >>>>> don't know a better one. Anybody else? (I think Paul J was the one >>>>> who raised this concern, so maybe he has an example.) >>>>> >>>>> If we can't find a plausible reason why we need to do this mapping, >>>>> then I propose that we just not bother. In that case I think >>>>> representation >>>>> #3 is attractive. It provides for the easiest comparison between id >>>>> values >>>>> - a single string comparison is sufficient. And its among the most >>>>> compact representations. I'd recommend: >>>>> >>>>> session-id: SmallestHalf:BiggestHalf >>>>> >>>>> Or just >>>>> >>>>> session-id: FirstHalf >>>>> >>>>> before the half for the far end has been assigned. >>>>> >>>>> Thanks, >>>>> Paul >>>>> _______________________________________________ >>>>> insipid mailing list >>>>> insipid@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/insipid >>>> >>>> >>> >>> _______________________________________________ >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From Henry.Lum@genesyslab.com Tue Jul 31 19:26:24 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 A808D21F875C for ; Tue, 31 Jul 2012 19:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=0.527, 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 jFdgM-pKHXYx for ; Tue, 31 Jul 2012 19:26:24 -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 9365521F8757 for ; Tue, 31 Jul 2012 19:26:07 -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 q712Q6Ou024738 for ; Tue, 31 Jul 2012 19:26:06 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 Jul 2012 19:26:06 -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: Tue, 31 Jul 2012 19:26:06 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF740806753E@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on draft-ietf-siprec-metadata-07 Thread-Index: Ac1vjQDN8zXHYxh0TdyfDVEBhvV+iQ== From: "Henry Lum" To: X-OriginalArrivalTime: 01 Aug 2012 02:26:06.0713 (UTC) FILETIME=[01567E90:01CD6F8D] Subject: [siprec] comments on draft-ietf-siprec-metadata-07 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, 01 Aug 2012 02:26:24 -0000 Hi, I notice that in the metadata model in section 4 CS has a 1..* to 0..* = relation with a media stream and this is inconsistent with further text. In section 6.3, CS is stating that it has a 0..* to 0..* relation with a = media stream. On top of page 12 it explains that a media stream can be = associated with zero of more CS and points out that a multicast MOH = stream can be without a CS. In section 6.7 a media stream can connect to = 1..* CS.=20 Which one is the intended usage? Note that XML requires the = session_id attribute so it seems like section 6.3 is odd one out. Regards, Henry From pkyzivat@alum.mit.edu Tue Jul 31 22: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 3D98321F8565 for ; Tue, 31 Jul 2012 22:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.366 X-Spam-Level: X-Spam-Status: No, score=-0.366 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 y4djYWkqxxZ6 for ; Tue, 31 Jul 2012 22:59:52 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 320F821F8564 for ; Tue, 31 Jul 2012 22:59:51 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta02.westchester.pa.mail.comcast.net with comcast id hHzM1j0080QuhwU51Hzu6K; Wed, 01 Aug 2012 05:59:54 +0000 Received: from dhcp-40e5.meeting.ietf.org ([IPv6:2001:df8:0:64:28ae:314c:9bbf:23ed]) by omta02.westchester.pa.mail.comcast.net with comcast id hHzg1j00210F03f3NHzgf5; Wed, 01 Aug 2012 05:59:40 +0000 Message-ID: <5018C5D5.4090207@alum.mit.edu> Date: Tue, 31 Jul 2012 22:59:49 -0700 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <059AF07365DC474393A19A3AF187DF740806753E@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF740806753E@NAHALD.us.int.genesyslab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] comments on draft-ietf-siprec-metadata-07 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, 01 Aug 2012 05:59:53 -0000 Hi Henry, Yes, I agree that there is an inconsistency. We have also been discussing problems with this association that we plan to talk about on Thursday. My proposal is to change it to: CS ------------------- Media Stream 0..1 0..* Thanks, Paul On 7/31/12 7:26 PM, Henry Lum wrote: > Hi, > > I notice that in the metadata model in section 4 CS has a 1..* to 0..* relation with a media stream and this is inconsistent with further text. > > In section 6.3, CS is stating that it has a 0..* to 0..* relation with a media stream. On top of page 12 it explains that a media stream can be associated with zero of more CS and points out that a multicast MOH stream can be without a CS. In section 6.7 a media stream can connect to 1..* CS. > > Which one is the intended usage? Note that XML requires the session_id attribute so it seems like section 6.3 is odd one out. > > Regards, > Henry > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >