From andrew.hutton@siemens-enterprise.com Fri May 4 00:58: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 E696621F86FC for ; Fri, 4 May 2012 00:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 mDaMmpe6wk9o for ; Fri, 4 May 2012 00:58:14 -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 E9E9921F8629 for ; Fri, 4 May 2012 00:58:13 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id A81A823F051F; Fri, 4 May 2012 09:58:12 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 4 May 2012 09:58:12 +0200 From: "Hutton, Andrew" To: "Charles Eckel (eckelcu)" , "siprec@ietf.org" , Henry Lum Date: Fri, 4 May 2012 09:58:11 +0200 Thread-Topic: [siprec] draft-eckel-siprec-rtp-rec-03 - Should we adopt in its own right. Thread-Index: Acz+BNDnrr4sVn7wTIWf9MiV5/IeIAozwQ1QAAXIqzAAt/HXEA== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31299283468@MCHP058A.global-ad.net> References: <101C6067BEC68246B0C3F6843BCCC1E312946BC60B@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E3129928266C@MCHP058A.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] draft-eckel-siprec-rtp-rec-03 - Should we adopt in its own right. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 07:58:15 -0000 Hi Charles, I agree let's do it. Richard Barnes volunteered to do a security review of the protocol document= we probably need to do the merge get the protocol draft up to date with th= e any other changes pending and get it out for review. Can you co-ordinate with Henry to get an update to the protocol draft out s= oon? Regards Andy > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > Sent: 30 April 2012 17:09 > To: Hutton, Andrew; siprec@ietf.org > Subject: RE: [siprec] draft-eckel-siprec-rtp-rec-03 - Should we adopt > in its own right. >=20 > Hi Andy, >=20 > I am fine with your proposal. I think the best way to do this would be > to add the content from draft-eckel-siprec-rtp-rec into section 7 of > draft-siprec-protocol, with editorial changes only. That way we have a > baseline of the RTP recommendations within the protocol document that > can be extended in subsequent updates to draft-siprec-protocol based on > the agreements from IETF 83. >=20 > Cheers, > Charles >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Hutton, Andrew > > Sent: Monday, April 30, 2012 6:24 AM > > To: siprec@ietf.org > > Subject: Re: [siprec] draft-eckel-siprec-rtp-rec-03 - Should we adopt > > in its own right. > > > > Hi All, > > > > Following the discussion we had at IETF83 there does not seem any > > consensus for adopting the RTP Considerations as separate draft to > the > > protocol draft so I think we need to go ahead and merge draft-eckel- > > siprec-rtp-rec into draft-siprec-protocol. > > > > Regards > > Andy (SIPREC Co-Chair). > > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Hutton, Andrew > > > Sent: 09 March 2012 14:57 > > > To: siprec@ietf.org > > > Subject: [siprec] draft-eckel-siprec-rtp-rec-03 - Should we adopt > in > > > its own right. > > > > > > Hi All, > > > > > > So far we always planned to at some point merge > > > http://tools.ietf.org/html/draft-eckel-siprec-rtp-rec-03 with our > > > protocol draft (http://tools.ietf.org/html/draft-ietf-siprec- > > protocol- > > > 03). > > > > > > However maybe it would be a good idea to keep these separate and > > adopt > > > draft-eckel-siprec-rtp-rec-*. I envisage that it would maintain > its > > > current states as "informational" only. > > > > > > I would be interested in the opinions of the group on this. > > > > > > Regards > > > Andy (SIPREC Co-Chair). > > > > > > _______________________________________________ > > > siprec mailing 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 Mon May 7 11:56: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 776F321F8534 for ; Mon, 7 May 2012 11:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 RYsuX2OH2Z2h for ; Mon, 7 May 2012 11:56:49 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC9E21F84E6 for ; Mon, 7 May 2012 11:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=3592; q=dns/txt; s=iport; t=1336417009; x=1337626609; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=2s9VEUPbz5ommeyQXcP3cCsomEjwYGMrPF6JmJN4ke4=; b=H1X5MNC5S9zT4STYR46CebnwFY4lZmT9bEOjjZLgvv86sHKmwJEO6gYd Ct9sdxI58CnrtczWquuYuCuvH/jME/O77IKLCyjvxRjINM4IHvwXsOppR 25embSkqAovlp6xjFmoo6LcnCcCXThfGjCT+0wr7Bg8rmj7hBb7uzBJ4W s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAF0aqE+rRDoI/2dsb2JhbABEsx+BB4IMAQEBBAEBAQ8BHQo0FwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHawELmw6gCop/hSZjBIhkjiuNSIFpgwk X-IronPort-AV: E=Sophos;i="4.75,545,1330905600"; d="scan'208";a="40722512" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 07 May 2012 18:56:48 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q47Ium6Q016262; Mon, 7 May 2012 18:56:48 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 May 2012 11:56:48 -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, 7 May 2012 11:56:48 -0700 Message-ID: In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31299283468@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] draft-eckel-siprec-rtp-rec-03 - Should we adopt in its own right. Thread-Index: Acz+BNDnrr4sVn7wTIWf9MiV5/IeIAozwQ1QAAXIqzAAt/HXEACuEIlQ References: <101C6067BEC68246B0C3F6843BCCC1E312946BC60B@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E3129928266C@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E31299283468@MCHP058A.global-ad.net> From: "Charles Eckel (eckelcu)" To: "Hutton, Andrew" , , "Henry Lum" X-OriginalArrivalTime: 07 May 2012 18:56:48.0855 (UTC) FILETIME=[28170E70:01CD2C83] Subject: Re: [siprec] draft-eckel-siprec-rtp-rec-03 - Should we adopt in its own right. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 18:56:50 -0000 Will do. Henry, unicast me to let me know your preference. I can send my xml file to you to incorporate, or you can send your xml file to me. Cheers, Charles > -----Original Message----- > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > Sent: Friday, May 04, 2012 12:58 AM > To: Charles Eckel (eckelcu); siprec@ietf.org; Henry Lum > Subject: RE: [siprec] draft-eckel-siprec-rtp-rec-03 - Should we adopt > in its own right. >=20 > Hi Charles, >=20 > I agree let's do it. >=20 > Richard Barnes volunteered to do a security review of the protocol > document we probably need to do the merge get the protocol draft up to > date with the any other changes pending and get it out for review. >=20 > Can you co-ordinate with Henry to get an update to the protocol draft > out soon? >=20 > Regards > Andy >=20 >=20 > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > Sent: 30 April 2012 17:09 > > To: Hutton, Andrew; siprec@ietf.org > > Subject: RE: [siprec] draft-eckel-siprec-rtp-rec-03 - Should we adopt > > in its own right. > > > > Hi Andy, > > > > I am fine with your proposal. I think the best way to do this would > be > > to add the content from draft-eckel-siprec-rtp-rec into section 7 of > > draft-siprec-protocol, with editorial changes only. That way we have > a > > baseline of the RTP recommendations within the protocol document that > > can be extended in subsequent updates to draft-siprec-protocol based > on > > the agreements from IETF 83. > > > > Cheers, > > Charles > > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Hutton, Andrew > > > Sent: Monday, April 30, 2012 6:24 AM > > > To: siprec@ietf.org > > > Subject: Re: [siprec] draft-eckel-siprec-rtp-rec-03 - Should we > adopt > > > in its own right. > > > > > > Hi All, > > > > > > Following the discussion we had at IETF83 there does not seem any > > > consensus for adopting the RTP Considerations as separate draft to > > the > > > protocol draft so I think we need to go ahead and merge draft- > eckel- > > > siprec-rtp-rec into draft-siprec-protocol. > > > > > > Regards > > > Andy (SIPREC Co-Chair). > > > > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > > Behalf Of Hutton, Andrew > > > > Sent: 09 March 2012 14:57 > > > > To: siprec@ietf.org > > > > Subject: [siprec] draft-eckel-siprec-rtp-rec-03 - Should we adopt > > in > > > > its own right. > > > > > > > > Hi All, > > > > > > > > So far we always planned to at some point merge > > > > http://tools.ietf.org/html/draft-eckel-siprec-rtp-rec-03 with our > > > > protocol draft (http://tools.ietf.org/html/draft-ietf-siprec- > > > protocol- > > > > 03). > > > > > > > > However maybe it would be a good idea to keep these separate and > > > adopt > > > > draft-eckel-siprec-rtp-rec-*. I envisage that it would maintain > > its > > > > current states as "informational" only. > > > > > > > > I would be interested in the opinions of the group on this. > > > > > > > > Regards > > > > Andy (SIPREC Co-Chair). > > > > > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec From pravindran@sonusnet.com Wed May 9 06:45:11 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 6E49F21F8609 for ; Wed, 9 May 2012 06:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.919 X-Spam-Level: X-Spam-Status: No, score=-5.919 tagged_above=-999 required=5 tests=[AWL=-0.521, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 K24+OXH8tTNc for ; Wed, 9 May 2012 06:45:06 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with ESMTP id E772621F85FC for ; Wed, 9 May 2012 06:45:02 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKT6p02WgkEtexpkaqsv2EYRM7QkApO3WE@postini.com; Wed, 09 May 2012 06:45:06 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 9 May 2012 09:45:07 -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, 9 May 2012 19:14:52 +0530 From: "Ravindran, Parthasarathi" To: "john.2.stafford@bt.com" , "siprec@ietf.org" Thread-Topic: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. Thread-Index: AQHNDPHbKGqRGqQpE0uaR07g0+NKr5aANujQgADFHNKAQLr/EA== Date: Wed, 9 May 2012 13:44:51 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C16033A85@inba-mail01.sonusnet.com> References: , <387F9047F55E8C42850AD6B3A7A03C6C0E221327@inba-mail01.sonusnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.99] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C16033A85inbamail01sonus_" MIME-Version: 1.0 Subject: Re: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 13:45:11 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C16033A85inbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John, Sorry for the delay reply. In the object model, there is unique-id and ass= ociation 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 mea= ning 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: 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 mix= ed stream and duplicated stream recording. Partha, so you are saying there is no need to allow multiple labels on a stream e= lement, as a stream elemet can be repeated in the metadata multiple times. I dont see how this matches the object model, a element with a unique id = can surely on occur once in the matadata. Rgds John Stafford | Solution Architect 1 | BT Global Services | Tel:+44 (0)1932= 773504 | E: john.2.stafford@bt.com | ww= w.bt.com/globalservices ________________________________ From: Ravindran, Parthasarathi [pravindran@sonusnet.com] Sent: 28 March 2012 22:42 To: Stafford,J,John,JRJ3X C; siprec@ietf.org Subject: RE: [siprec] Proposal for minor changes to metadata to support mix= ed stream and duplicated stream recording. John, I'll explain how to form metadata XML element for your requirement: "Siprec support for recording same CS stream in multiple m line streams of = 1 RS: This is the converse of the above, I propose that multiple labels be all= owed in a stream element, the meaning would be that the stream is recorded in all of the reference= d recording m-line streams." Here, There are two CS's, 2 m'line and 1 RS. For representing as per curr= ent XML schema is as follows, Could you please explain the issue in the above approach. Thanks Partha From: siprec-bounces@ietf.org [mailto:sipre= c-bounces@ietf.org] On Behalf Of john.2.stafford@bt.com Sent: Wednesday, March 28, 2012 8:19 PM To: siprec@ietf.org Subject: [siprec] Proposal for minor changes to metadata to support mixed s= tream and duplicated stream recording. This is as follow up to the threads "How to specify in metadata that multiple CS's are being recorded in a s= ingle mixed RS m line stream" http://www.ietf.org/mail-archive/web/siprec/current/msg03126.html "How to specify in metadata that a participants stream is being recorded= in multiple m line streams" http://www.ietf.org/mail-archive/web/siprec/current/msg03107.html Siprec support for mixed stream recording: I propose multiple streams would use the same label, indicating that the streams are recorded in the same recording m-line st= ream. Siprec support for recording same CS stream in multiple m line streams of 1= RS: This is the converse of the above, I propose that multiple labels be all= owed in a stream element, the meaning would be that the stream is recorded in all of the reference= d recording m-line streams. Implications for existing metadata specification: This does not change the existing metadata usage of streams and labels, = it just adds more flexibility. The only changes required would be that 1. stream's label element maxoccurs=3D"1" restriction would need to = be removed 2. there would be a 1:n stream:label relationship not 1:1. I can't see anything in draft-ietf-siprec-metadata-06 that says th= ere is a 1:1 relationship anyway. Examples: Mixed Stream Recording: If we have a persistent RS with a single m-line, and a single CS bein= g recorded via a mixed TX/RX stream, then the metadata will have a single element, which has a lab= el referencing a RS m-line. Now if we add a 2nd CS to that RS, we will now have two elem= ents, one for each CS. If they are both being mixed onto the one RS m-line stream, both elements will have the same label, ie: Duplicate Stream Recording If we have a persistent RS with a single m-line, and a single CS bein= g recorded via a mixed TX/RX stream, then the metadata will have a single element, which has a la= bel referencing a RS m-line. If we have a a persistent RS with a two m-line's for duplicated recor= ding, then the metadata will have a single element, which has a two lab= els referencing both the RS m-lines. Finally, we could have both the above scenarios together, where the mixe= d two CS recording is duplicated: So why do I think siprec should support these changes ? Requirements for mixed stream recording: RFC6341 refers to mixed recording in use cases 3 and 11 and in REQ 9:= : In Use Case 3: In some cases, more than one concurrent Communication Session (on a single end-user apparatus, e.g., trading-floor turret) is mixed into one Recording Session: |-------- CS 1 -------| |-------- CS 2 -------| |-------- CS 3 -------| RS |----------- Recording Session --------------| t---> In Use case 11: In trading-floor environments, in order to minimize storage and recording system resources, it may be preferable to mix multiple concurrent calls (Communication Sessions) on different handsets/ speakers on the same turret into a single recording session. REQ-009: The mechanism MUST support the ability for an SRC to deliver mixed audio streams from different parties of a given Communication Session to an SRS. To me this implies multiple CS's in one mixed recorder stream, since = the requirement specifically says "mix", and "to minimise storage". Requirements for Duplicated stream recording: RFC6341 does not specifically mention duplicated recording But I don't think allowing it would complicate the metadata, and it w= ill be down to the recorder implementation how it handles the duplicated CS recording. Rgds John Stafford | Solution Architect 1 | BT Global Services --_000_387F9047F55E8C42850AD6B3A7A03C6C16033A85inbamail01sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi John,

 <= /p>

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 th= e object is represented by second attribute .

 <= /p>

While I discussing with X= ML experts, I understand that “id” has special meaning in XML a= nd it should not be repeated. So, I’m proposing to have object name with id for both attributes and XML looks as follows:

 <= /p>

  &= nbsp;   <stream stream_id=3D"Axzg12XHdhjelfjhdldjf;34jn78= =3D=3D"
            &nb= sp;       session_id=3D"zzlafnvvjlCHllaH= F6mn8kkSS=3D=3D”>
            &nb= sp;       <label>99</label>
       </stream>

  &= nbsp;   <stream stream_id=3D"Axzg12XHdhjelfjhdldjf;34jn78= =3D=3D"
            &nb= sp;       session_id=3D" zSfPoSvdSDCmU3A= 3TRDxAw=3D=3D”>
            &nb= sp;       <label>99</label>
       </stream>
      <stream stream_id=3D"EiXGlc+4Tru= qqoDaNE76ag=3D=3D"
            &nb= sp;       session_id=3D" zzlafnvvjlCHlla= HF6mn8kkSS=3D=3D">
            &nb= sp;       <label>100</label>
       </stream>

  &= nbsp;   <stream stream_id=3D"EiXGlc+4TruqqoDaNE76ag= =3D=3D"
            &nb= sp;       session_id=3D"zSfPoSvdSDCmU3A3= TRDxAw=3D=3D">
            &nb= sp;      <label>99</label>
       </stream>

 <= /p>

Please let me know your o= pinion on the same.

 <= /p>

Thanks<= /p>

Partha<= /p>

 <= /p>

 <= /p>

From: john.2.s= tafford@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 supp= ort mixed stream and duplicated stream recording.

 

Partha,

 

  so you are saying the= re is no need to allow multiple labels on a stream element, as a stream ele= met can be repeated in the metadata multiple times.

 

  I dont see how this m= atches the object model, a element with a unique id can surely on occur onc= e in the matadata.

 

 

Rgds

John Stafford | Solution Architect 1 | BT Global Se= rvices | Tel:+44 (0)1932 773504   | E= : john.2.stafford@bt.com  |  www.bt.com/globalservices

 =

 

From: Ravindran, Parthasarathi [pr= avindran@sonusnet.com]
Sent: 28 March 2012 22:42
To: Stafford,J,John,JRJ3X C; sipr= ec@ietf.org
Subject: RE: [siprec] Proposal for minor changes to metadata to supp= ort 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 lab= els be allowed in a  stream element,
   the meaning would be that the stream is recorded in all of the= referenced recording m-line streams.”

 =

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

 =

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

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

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

 =

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

 =

Thanks

Partha

 =

From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of john.2.staffo= rd@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/sipr= ec/current/msg03126.html<= /span>


   “How to specify in metadata that a participants stream i= s being recorded in multiple m line streams”
    http://www.ietf.org/mail-archive/web/siprec/current/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 strea= m.
 
Siprec support for recording same CS stream in multiple m line streams of 1= RS:
   This is the converse of the above, I propose that multiple lab= els be allowed in a  stream element,
   the meaning would be that the stream is recorded in all of the= referenced recording m-line streams.
 

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


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

 =

 =


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

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

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

 =

Rgds

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

--_000_387F9047F55E8C42850AD6B3A7A03C6C16033A85inbamail01sonus_-- From pkyzivat@alum.mit.edu Wed May 9 07:15:17 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D083411E8072 for ; Wed, 9 May 2012 07:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=-0.475, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNUfarEP3DXN for ; Wed, 9 May 2012 07:15:17 -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 B36BD11E8079 for ; Wed, 9 May 2012 07:15:16 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta15.westchester.pa.mail.comcast.net with comcast id 7nmZ1j0021c6gX85FqFHHC; Wed, 09 May 2012 14:15:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta23.westchester.pa.mail.comcast.net with comcast id 7qFG1j01X07duvL3jqFGcg; Wed, 09 May 2012 14:15:17 +0000 Message-ID: <4FAA7BF3.3080202@alum.mit.edu> Date: Wed, 09 May 2012 10:15:15 -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: , <387F9047F55E8C42850AD6B3A7A03C6C0E221327@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C16033A85@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C16033A85@inba-mail01.sonusnet.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 14:15:17 -0000 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="zzlafnvvjlCHllaHF6mn8kkSS==”> > > > > session_id=" zSfPoSvdSDCmU3A3TRDxAw==”> > > > session_id=" zzlafnvvjlCHllaHF6mn8kkSS=="> > > > > session_id="zSfPoSvdSDCmU3A3TRDxAw=="> > > > > 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="zzlafnvvjlCHllaHF6mn8kkSS==”> > > > > session=" zSfPoSvdSDCmU3A3TRDxAw==”> > > > session=" zzlafnvvjlCHllaHF6mn8kkSS=="> > > > > session="zSfPoSvdSDCmU3A3TRDxAw=="> > > > > Could you please explain the issue in the above approach. > > Thanks > > Partha > > *From:*siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] *On Behalf Of *john.2.stafford@bt.com > > *Sent:* Wednesday, March 28, 2012 8:19 PM > *To:* siprec@ietf.org > *Subject:* [siprec] Proposal for minor changes to metadata to support > mixed stream and duplicated stream recording. > > > This is as follow up to the threads > “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=”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="zzlafnvvjlCHllaHF6mn8kkSS==”> > > > session="zSfPoSvdSDCmU3A3TRDxAw=="> > > > > > > > Duplicate Stream Recording > If we have a persistent RS with a single m-line, and a single CS being > recorded via a mixed TX/RX stream, > then the metadata will have a single element, which has a label > referencing a RS m-line. > > If we have a a persistent RS with a two m-line’s for duplicated > recording, then > the metadata will have a single element, which has a two labels > referencing both the RS m-lines. > > session="zzlafnvvjlCHllaHF6mn8kkSS==”> > > > > > > Finally, we could have both the above scenarios together, where the > mixed two CS recording is duplicated: > > session="zzlafnvvjlCHllaHF6mn8kkSS==”> > > > > session="zSfPoSvdSDCmU3A3TRDxAw=="> > > > > > > > So why do I think siprec should support these changes ? > > > Requirements for mixed stream recording: > > RFC6341 refers to mixed recording in use cases 3 and 11 and in REQ 9:: > > In Use Case 3: > In some cases, more than one concurrent Communication Session (on > a single end-user apparatus, e.g., trading-floor turret) is mixed > into one Recording Session: > > |-------- CS 1 -------| > |-------- CS 2 -------| > |-------- CS 3 -------| > > RS |----------- Recording Session --------------| > t---> > > In Use case 11: > In trading-floor environments, in order to minimize storage and > recording system resources, it may be preferable to mix multiple > concurrent calls (Communication Sessions) on different handsets/ > speakers on the same turret into a single recording session. > > REQ-009: The mechanism MUST support the ability for an SRC to > deliver mixed audio streams from different parties of a given > Communication Session to an SRS. > > > 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 From internet-drafts@ietf.org Wed May 9 07:38:15 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B36611E8093; Wed, 9 May 2012 07:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cohmJUafmWsu; Wed, 9 May 2012 07:38:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B4411E8072; Wed, 9 May 2012 07:38:15 -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.02 Message-ID: <20120509143815.28864.42653.idtracker@ietfa.amsl.com> Date: Wed, 09 May 2012 07:38:15 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-protocol-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 14:38:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Recording Working Group of the IE= TF. Title : Session Recording Protocol Author(s) : Leon Portman Henry Lum Charles Eckel Alan Johnston Andrew Hutton Filename : draft-ietf-siprec-protocol-04.txt Pages : 34 Date : 2012-05-09 This document specifies the use of the Session Initiation Protocol (SIP), the Session Description Protocol (SDP), and the Real Time Protocol (RTP) for delivering real-time media and metadata from a Communication Session (CS) to a recording device. The Session Recording Protocol specifies the use of SIP, SDP, and RTP to establish a Recording Session (RS) between the Session Recording Client (SRC), which is on the path of the CS, and a Session Recording Server (SRS) at the recording device. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-siprec-protocol-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-protocol-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol/ From Henry.Lum@genesyslab.com Wed May 9 07:41:22 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0C711E809A for ; Wed, 9 May 2012 07:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.651, 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 UZsBOY0WWBXl for ; Wed, 9 May 2012 07:41:21 -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 D91FC11E8072 for ; Wed, 9 May 2012 07:41:21 -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 q49EfLF7012484 for ; Wed, 9 May 2012 07:41:21 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 May 2012 07:41:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 9 May 2012 07:41:19 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF74087F69A1@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-siprec-protocol-04.txt Thread-Index: Ac0t8V7wz2ecOSSzRDSGVcT3kAdXfAAADQgQ From: "Henry Lum" To: X-OriginalArrivalTime: 09 May 2012 14:41:21.0272 (UTC) FILETIME=[CCF6FF80:01CD2DF1] Subject: [siprec] FW: New Version Notification for draft-ietf-siprec-protocol-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 14:41:22 -0000 SGksDQoNCkkgaGF2ZSBtZXJnZWQgdGhlIFJUUCBkcmFmdCBpbnRvIHRoZSBwcm90b2NvbCBkcmFm dC4gSXQncyBiYXNpY2FsbHkgYSBjb3B5LWFuZC1wYXN0ZSBhdCB0aGlzIHBvaW50IGFuZCBubyBv dGhlciBjaGFuZ2VzIGhhdmUgYmVlbiBtYWRlIHNpbmNlIC0wMy4NCg0KUmVnYXJkcywNCkhlbnJ5 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTWF5LTA5LTEy IDEwOjM4IEFNDQpUbzogSGVucnkgTHVtDQpDYzogbGVvbi5wb3J0bWFuQG5pY2UuY29tOyBhbGFu LmIuam9obnN0b25AZ21haWwuY29tOyBhbmRyZXcuaHV0dG9uQHNpZW1lbnMtZW50ZXJwcmlzZS5j b207IGVja2VsY3VAY2lzY28uY29tDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWlldGYtc2lwcmVjLXByb3RvY29sLTA0LnR4dA0KDQpBIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQtaWV0Zi1zaXByZWMtcHJvdG9jb2wtMDQudHh0IGhhcyBiZWVuIHN1Y2Nlc3Nm dWxseSBzdWJtaXR0ZWQgYnkgSGVucnkgTHVtIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3Np dG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1pZXRmLXNpcHJlYy1wcm90b2NvbA0KUmV2aXNpb246 CSAwNA0KVGl0bGU6CQkgU2Vzc2lvbiBSZWNvcmRpbmcgUHJvdG9jb2wNCkNyZWF0aW9uIGRhdGU6 CSAyMDEyLTA1LTA4DQpXRyBJRDoJCSBzaXByZWMNCk51bWJlciBvZiBwYWdlczogMzQNCg0KQWJz dHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0aGUgdXNlIG9mIHRoZSBTZXNzaW9u IEluaXRpYXRpb24gUHJvdG9jb2wNCiAgIChTSVApLCB0aGUgU2Vzc2lvbiBEZXNjcmlwdGlvbiBQ cm90b2NvbCAoU0RQKSwgYW5kIHRoZSBSZWFsIFRpbWUNCiAgIFByb3RvY29sIChSVFApIGZvciBk ZWxpdmVyaW5nIHJlYWwtdGltZSBtZWRpYSBhbmQgbWV0YWRhdGEgZnJvbSBhDQogICBDb21tdW5p Y2F0aW9uIFNlc3Npb24gKENTKSB0byBhIHJlY29yZGluZyBkZXZpY2UuICBUaGUgU2Vzc2lvbg0K ICAgUmVjb3JkaW5nIFByb3RvY29sIHNwZWNpZmllcyB0aGUgdXNlIG9mIFNJUCwgU0RQLCBhbmQg UlRQIHRvDQogICBlc3RhYmxpc2ggYSBSZWNvcmRpbmcgU2Vzc2lvbiAoUlMpIGJldHdlZW4gdGhl IFNlc3Npb24gUmVjb3JkaW5nDQogICBDbGllbnQgKFNSQyksIHdoaWNoIGlzIG9uIHRoZSBwYXRo IG9mIHRoZSBDUywgYW5kIGEgU2Vzc2lvbiBSZWNvcmRpbmcNCiAgIFNlcnZlciAoU1JTKSBhdCB0 aGUgcmVjb3JkaW5nIGRldmljZS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRo ZSBJRVRGIFNlY3JldGFyaWF0DQo= From pravindran@sonusnet.com Thu May 10 06:13: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 6EA8821F866D for ; Thu, 10 May 2012 06:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.906 X-Spam-Level: X-Spam-Status: No, score=-5.906 tagged_above=-999 required=5 tests=[AWL=-0.507, BAYES_00=-2.599, 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 IM3R1q+xfl1O for ; Thu, 10 May 2012 06:13:32 -0700 (PDT) Received: from na3sys010aog114.obsmtp.com (na3sys010aog114.obsmtp.com [74.125.245.96]) by ietfa.amsl.com (Postfix) with ESMTP id 7598021F8665 for ; Thu, 10 May 2012 06:13:31 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob114.postini.com ([74.125.244.12]) with SMTP ID DSNKT6u++ppGbwREl3zmSkqMyvX+jVzsGdMO@postini.com; Thu, 10 May 2012 06:13:31 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; Thu, 10 May 2012 09:13:42 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Thu, 10 May 2012 18:43:26 +0530 From: "Ravindran, Parthasarathi" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. Thread-Index: AQHNDPHbKGqRGqQpE0uaR07g0+NKr5aANujQgADFHNKAQLr/EP//rzSAgAHcSUA= Date: Thu, 10 May 2012 13:13:25 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C16033D60@inba-mail01.sonusnet.com> References: , <387F9047F55E8C42850AD6B3A7A03C6C0E221327@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C16033A85@inba-mail01.sonusnet.com> <4FAA7BF3.3080202@alum.mit.edu> In-Reply-To: <4FAA7BF3.3080202@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.99] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jhildebr@cisco.com" Subject: Re: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 13:13:33 -0000 Paul, XML:id attribute is mentioned in http://www.w3.org/TR/xml-id/ and each elem= ent 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"> >> > 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 >> [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 From jhildebr@cisco.com Thu May 10 08:20: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 A232F21F86B8 for ; Thu, 10 May 2012 08:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.632 X-Spam-Level: X-Spam-Status: No, score=-7.632 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_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 Yz0qEM3q2ZiA for ; Thu, 10 May 2012 08:20:06 -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 3E29421F866A for ; Thu, 10 May 2012 08:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10307; q=dns/txt; s=iport; t=1336663206; x=1337872806; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=2aQbI4/Xfn9QA4uBjunNBLrdCTJwoLWmgFdA8gFd650=; b=M38fMt5BdZgiOm1veHFSfR6D58GV73hBPLE9iR+MBorMzoNTtjTo044X /qKqm0vqJYR0qwXJP42m3uW4ybns8T8dC5+eyIHN5aU3rqJwAYqonPA60 F8pYUMnR0whIdxCVolAieE+2gJimoWkHQBMjI2SSKnu8RK/UzPzjm86q9 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwHAEHcq0+tJV2a/2dsb2JhbABEDrN/AoEHghUBAQEDAQEBAQ8BFBMCAS4DBAwHBgEIEQQBAQEjBC4fCQgCBAESCRIHh2cFC5sYoB+LEhkIhggEiGSNGYtAgxeBaYIwWIE4CA X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="79059216" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 10 May 2012 15:20:05 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q4AFK5WG016233; Thu, 10 May 2012 15:20:05 GMT Received: from xmb-rcd-313.cisco.com ([72.163.63.28]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 May 2012 10:20:05 -0500 Received: from 64.101.74.200 ([64.101.74.200]) by XMB-RCD-313.cisco.com ([72.163.63.28]) with Microsoft Exchange Server HTTP-DAV ; Thu, 10 May 2012 15:20:05 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 10 May 2012 09:20:04 -0600 From: Joe Hildebrand To: "Ravindran, Parthasarathi" , Paul Kyzivat , "siprec@ietf.org" Message-ID: Thread-Topic: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. Thread-Index: AQHNDPHbKGqRGqQpE0uaR07g0+NKr5aANujQgADFHNKAQLr/EP//rzSAgAHcSUCAACRbRw== In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C16033D60@inba-mail01.sonusnet.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 May 2012 15:20:05.0510 (UTC) FILETIME=[60BB5260:01CD2EC0] X-Mailman-Approved-At: Thu, 10 May 2012 08:32:12 -0700 Subject: Re: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 15:20:07 -0000 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. 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="zzlafnvvjlCHllaHF6mn8kkSS=="> >>> >>> >>> >>> >> session_id=" zSfPoSvdSDCmU3A3TRDxAw=="> >>> >> session_id=" zzlafnvvjlCHllaHF6mn8kkSS=="> >>> >>> >>> >> session_id="zSfPoSvdSDCmU3A3TRDxAw=="> >>> >>> >>> >>> 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="zzlafnvvjlCHllaHF6mn8kkSS=="> >>> >>> >>> >>> >> session=" zSfPoSvdSDCmU3A3TRDxAw=="> >>> >>> >>> >> session=" zzlafnvvjlCHllaHF6mn8kkSS=="> >>> >>> >> session="zSfPoSvdSDCmU3A3TRDxAw=="> >>> >>> >>> >>> Could you please explain the issue in the above approach. >>> >>> Thanks >>> >>> Partha >>> >>> *From:*siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org] *On Behalf Of *john.2.stafford@bt.com >>> >>> *Sent:* Wednesday, March 28, 2012 8:19 PM >>> *To:* siprec@ietf.org >>> *Subject:* [siprec] Proposal for minor changes to metadata to support >>> mixed stream and duplicated stream recording. >>> >>> >>> This is as follow up to the threads >>> "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="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="zzlafnvvjlCHllaHF6mn8kkSS=="> >>> >>> >>> >> session="zSfPoSvdSDCmU3A3TRDxAw=="> >>> >>> >>> >>> >>> >>> >>> Duplicate Stream Recording >>> If we have a persistent RS with a single m-line, and a single CS being >>> recorded via a mixed TX/RX stream, then the metadata will have a >>> single element, which has a label referencing a RS m-line. >>> >>> If we have a a persistent RS with a two m-line's for duplicated >>> recording, then the metadata will have a single element, >>> which has a two labels referencing both the RS m-lines. >>> >>> >> session="zzlafnvvjlCHllaHF6mn8kkSS=="> >>> >>> >>> >>> >>> >>> Finally, we could have both the above scenarios together, where the >>> mixed two CS recording is duplicated: >>> >>> >> session="zzlafnvvjlCHllaHF6mn8kkSS=="> >>> >>> >>> >>> >> session="zSfPoSvdSDCmU3A3TRDxAw=="> >>> >>> >>> >>> >>> >>> >>> So why do I think siprec should support these changes ? >>> >>> >>> Requirements for mixed stream recording: >>> >>> RFC6341 refers to mixed recording in use cases 3 and 11 and in REQ 9:: >>> >>> In Use Case 3: >>> In some cases, more than one concurrent Communication Session (on a >>> single end-user apparatus, e.g., trading-floor turret) is mixed into >>> one Recording Session: >>> >>> |-------- CS 1 -------| >>> |-------- CS 2 -------| >>> |-------- CS 3 -------| >>> >>> RS |----------- Recording Session --------------| >>> t---> >>> >>> In Use case 11: >>> In trading-floor environments, in order to minimize storage and >>> recording system resources, it may be preferable to mix multiple >>> concurrent calls (Communication Sessions) on different handsets/ >>> speakers on the same turret into a single recording session. >>> >>> REQ-009: The mechanism MUST support the ability for an SRC to deliver >>> mixed audio streams from different parties of a given Communication >>> Session to an SRS. >>> >>> >>> 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 -- Joe Hildebrand From pkyzivat@alum.mit.edu Thu May 10 13:02: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 127C821F8644 for ; Thu, 10 May 2012 13:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.875 X-Spam-Level: X-Spam-Status: No, score=-1.875 tagged_above=-999 required=5 tests=[AWL=-0.476, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mChJZoryWGKd for ; Thu, 10 May 2012 13:02:38 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABF921F85AE for ; Thu, 10 May 2012 13:02:38 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta01.westchester.pa.mail.comcast.net with comcast id 8K5C1j0071vXlb851L2fu8; Thu, 10 May 2012 20:02:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta17.westchester.pa.mail.comcast.net with comcast id 8L2e1j00Y07duvL3dL2e95; Thu, 10 May 2012 20:02:38 +0000 Message-ID: <4FAC1EDD.8030800@alum.mit.edu> Date: Thu, 10 May 2012 16:02: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: Joe Hildebrand References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 20:02:40 -0000 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="zzlafnvvjlCHllaHF6mn8kkSS=="> >>>> >>>> >>>> >>>> >>> session_id=" zSfPoSvdSDCmU3A3TRDxAw=="> >>>> >>> session_id=" zzlafnvvjlCHllaHF6mn8kkSS=="> >>>> >>>> >>>> >>> session_id="zSfPoSvdSDCmU3A3TRDxAw=="> >>>> >>>> >>>> >>>> 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="zzlafnvvjlCHllaHF6mn8kkSS=="> >>>> >>>> >>>> >>>> >>> session=" zSfPoSvdSDCmU3A3TRDxAw=="> >>>> >>>> >>>> >>> session=" zzlafnvvjlCHllaHF6mn8kkSS=="> >>>> >>>> >>> session="zSfPoSvdSDCmU3A3TRDxAw=="> >>>> >>>> >>>> >>>> Could you please explain the issue in the above approach. >>>> >>>> Thanks >>>> >>>> Partha >>>> >>>> *From:*siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] *On Behalf Of *john.2.stafford@bt.com >>>> >>>> *Sent:* Wednesday, March 28, 2012 8:19 PM >>>> *To:* siprec@ietf.org >>>> *Subject:* [siprec] Proposal for minor changes to metadata to support >>>> mixed stream and duplicated stream recording. >>>> >>>> >>>> This is as follow up to the threads >>>> "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="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="zzlafnvvjlCHllaHF6mn8kkSS=="> >>>> >>>> >>>> >>> session="zSfPoSvdSDCmU3A3TRDxAw=="> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Duplicate Stream Recording >>>> If we have a persistent RS with a single m-line, and a single CS being >>>> recorded via a mixed TX/RX stream, then the metadata will have a >>>> single element, which has a label referencing a RS m-line. >>>> >>>> If we have a a persistent RS with a two m-line's for duplicated >>>> recording, then the metadata will have a single element, >>>> which has a two labels referencing both the RS m-lines. >>>> >>>> >>> session="zzlafnvvjlCHllaHF6mn8kkSS=="> >>>> >>>> >>>> >>>> >>>> >>>> Finally, we could have both the above scenarios together, where the >>>> mixed two CS recording is duplicated: >>>> >>>> >>> session="zzlafnvvjlCHllaHF6mn8kkSS=="> >>>> >>>> >>>> >>>> >>> session="zSfPoSvdSDCmU3A3TRDxAw=="> >>>> >>>> >>>> >>>> >>>> >>>> >>>> So why do I think siprec should support these changes ? >>>> >>>> >>>> Requirements for mixed stream recording: >>>> >>>> RFC6341 refers to mixed recording in use cases 3 and 11 and in REQ 9:: >>>> >>>> In Use Case 3: >>>> In some cases, more than one concurrent Communication Session (on a >>>> single end-user apparatus, e.g., trading-floor turret) is mixed into >>>> one Recording Session: >>>> >>>> |-------- CS 1 -------| >>>> |-------- CS 2 -------| >>>> |-------- CS 3 -------| >>>> >>>> RS |----------- Recording Session --------------| >>>> t---> >>>> >>>> In Use case 11: >>>> In trading-floor environments, in order to minimize storage and >>>> recording system resources, it may be preferable to mix multiple >>>> concurrent calls (Communication Sessions) on different handsets/ >>>> speakers on the same turret into a single recording session. >>>> >>>> REQ-009: The mechanism MUST support the ability for an SRC to deliver >>>> mixed audio streams from different parties of a given Communication >>>> Session to an SRS. >>>> >>>> >>>> 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 > From john.2.stafford@bt.com Mon May 14 04:52: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 194FB21F84CF for ; Mon, 14 May 2012 04:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDloxtwir00f for ; Mon, 14 May 2012 04:52:33 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 5301B21F846F for ; Mon, 14 May 2012 04:52:33 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 14 May 2012 12:52:29 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.110]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Mon, 14 May 2012 12:52:29 +0100 From: To: Date: Mon, 14 May 2012 12:52:29 +0100 Thread-Topic: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. Thread-Index: Ac0u5+QDf2NqHjVQQ5uQ97R+fiu53wC3Y4nF Message-ID: References: , <4FAC1EDD.8030800@alum.mit.edu> In-Reply-To: <4FAC1EDD.8030800@alum.mit.edu> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: siprec@ietf.org Subject: Re: [siprec] 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: Mon, 14 May 2012 11:52:35 -0000 Partha,=20 You are suggesting=20 >>>> >>> session_id=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> >>>> >>>> >>>> >>>> >>> session_id=3D" zSfPoSvdSDCmU3A3TRDxAw=3D=3D"> =20 >>>> >>> 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 followin= g, 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 K= yzivat [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 mix= ed 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 processi= ng > software (such as CSS), id has special syntax that takes advantage of tha= t > 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 e= lement >> 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 Behal= f >>> 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"> >>>> >>> 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 >>>> [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= From pravindran@sonusnet.com Mon May 14 05:10: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 CCBBD21F8551 for ; Mon, 14 May 2012 05:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.595 X-Spam-Level: X-Spam-Status: No, score=-5.595 tagged_above=-999 required=5 tests=[AWL=-0.796, 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 WiRMyeOb8nDV for ; Mon, 14 May 2012 05:10:04 -0700 (PDT) Received: from na3sys010aog104.obsmtp.com (na3sys010aog104.obsmtp.com [74.125.245.76]) by ietfa.amsl.com (Postfix) with ESMTP id C43B221F84AA for ; Mon, 14 May 2012 05:10:03 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob104.postini.com ([74.125.244.12]) with SMTP ID DSNKT7D2G1j834UBUETu/immMAhEI36rKzHv@postini.com; Mon, 14 May 2012 05:10:03 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 14 May 2012 08:10:16 -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; Mon, 14 May 2012 17:39:58 +0530 From: "Ravindran, Parthasarathi" To: "john.2.stafford@bt.com" Thread-Topic: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. Thread-Index: AQHNDPHbKGqRGqQpE0uaR07g0+NKr5aANujQgADFHNKAQLr/EP//rzSAgAHcSUCAACRbR///8r+AgAXAYoCAAF0f0A== Date: Mon, 14 May 2012 12:09:58 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C16034636@inba-mail01.sonusnet.com> References: , <4FAC1EDD.8030800@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.99] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 12:10:05 -0000 John, My example is to show how to represent single stream in two CS and it is as= follows: In the above example, Axzg12XHdhjelfjhdldjf;34jn78=3D=3D is the single stre= am id which is Used by two CS namely zzlafnvvjlCHllaHF6mn8kkSS=3D=3D &=20 zSfPoSvdSDCmU3A3TRDxAw=3D=3D.=20 The trouble with multiple label in single stream is that the handling of=20 participantstream association for each of the label individually within the= single=20 stream element. =20 Duplicate stream recording has to have separate streams to distinguish the = actual &=20 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"> >>>>> >>>> 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 >>>>> [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 From pravindran@sonusnet.com Wed May 16 00:30: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 A6F9521F86FE for ; Wed, 16 May 2012 00:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.573 X-Spam-Level: X-Spam-Status: No, score=-5.573 tagged_above=-999 required=5 tests=[AWL=-0.774, 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 cbQ223rbOnWk for ; Wed, 16 May 2012 00:30:19 -0700 (PDT) Received: from na3sys010aog114.obsmtp.com (na3sys010aog114.obsmtp.com [74.125.245.96]) by ietfa.amsl.com (Postfix) with ESMTP id D80EE21F8642 for ; Wed, 16 May 2012 00:30:18 -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 DSNKT7NXiq9/hHHr3aDxLooS3HZwJnzK4dZJ@postini.com; Wed, 16 May 2012 00:30:18 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 16 May 2012 03:30:33 -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, 16 May 2012 13:00:13 +0530 From: "Ravindran, Parthasarathi" To: "Ravindran, Parthasarathi" , "john.2.stafford@bt.com" Thread-Topic: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. Thread-Index: AQHNDPHbKGqRGqQpE0uaR07g0+NKr5aANujQgADFHNKAQLr/EP//rzSAgAHcSUCAACRbR///8r+AgAXAYoCAAF0f0IAC2bZg Date: Wed, 16 May 2012 07:30:12 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C16034E25@inba-mail01.sonusnet.com> References: , <4FAC1EDD.8030800@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C16034636@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C16034636@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.99] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 07:30:21 -0000 Hi all, In case there is no objection to the below proposal with explicit id instea= d of "id" usage till 23rd May (Next Wednesday), I think that it is better t= o incorporate in (-07) metadata draft as these changes helps for the progre= sses 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"> >>>>>> >>>>> 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 >>>>>> [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 From andrew.hutton@siemens-enterprise.com Fri May 18 07:14:17 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC6621F8658 for ; Fri, 18 May 2012 07:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 yW3FQjhLWT+H for ; Fri, 18 May 2012 07:14:17 -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 3487921F8657 for ; Fri, 18 May 2012 07:14:17 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 4483323F086C; Fri, 18 May 2012 16:14:16 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 18 May 2012 16:14:16 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" , Leon Portman Date: Fri, 18 May 2012 16:14:14 +0200 Thread-Topic: Status of draft-siprec-architecture. Thread-Index: Ac01AIEuOYxaM3nITvCM2WfwZmo2Xw== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312A763464D@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Status of draft-siprec-architecture. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 14:14:18 -0000 Hi All, Following the WGLC and the discussion at IETF83 we have I think to make one= further update to draft-ietf-siprec-architecture before passing it on to t= he IESG. The mostly editorial comments from Ram and Charles from the following two e= -mail's need to be taken in to account. http://www.ietf.org/mail-archive/web/siprec/current/msg03204.html http://www.ietf.org/mail-archive/web/siprec/current/msg03210.html Section 3.3.2 I think we previously agreed to remove the text "Possibly usi= ng the Join header". >From discussion at IETF83 Paul Kyzivat suggested that we could remove secti= on 3.1.3 "A SIP Proxy cannot be a Session Recording Client". I did not hea= r any objections to this. Also at IET83 we discussed the statement in 3.1.1 regarding the B2BUA being= responsible for honouring the indication from a UA not to record. Charles = suggested that the current wording made it sound mandatory but I think we a= re in agreement that we don't want to have to enforce this and so the wordi= ng should be watered down a little bit to say that the "B2BUA/SRC may honou= r the indication....". Leon, would you be able to update the draft soon? We need to update the milestone and I am hoping that getting this draft to = the IESG before the next IETF meeting is a reasonable objective? Regards Andy From leon.portman@gmail.com Fri May 18 07:16: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 D307B21F867A for ; Fri, 18 May 2012 07:16:52 -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 Oj+SJlq8LLxM for ; Fri, 18 May 2012 07:16:52 -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 14FD121F8657 for ; Fri, 18 May 2012 07:16:51 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1969668wgb.13 for ; Fri, 18 May 2012 07:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=6C8hXYjSHtSVzTdlndRMq5QkvMYX46LmczafqWAZbXU=; b=CKSFgK2iy4HorT51r3KLJmZtv02jjxfhT3IX6IyQUr/iLH9Hho4GAJ8FoQ4ynYd9PF kHh16Sr5Mib/M4THsSUszGtJvEtid69scOvKoWU07fUC2707va4dPjkgOYqou749RmPd QWVM2wTC2d3VfVFaCprRFotXAJfFl1wKgysg4GRrfUiTjBqKuTy0nyrpu0BqOmranqXX NeLLINyKfcganhKGIOO4Pu4BsU+D5tDVCkKrqG/FLmqbSCZzX1npAl46ATtcL5pXN42a a6wVYpa3cVmR36wHNcALLNuGa8JIgfBBqRIeKa6Qa3yJXPkf8hcL/CMoza2v5Mn36O3K 0cjQ== Received: by 10.180.80.97 with SMTP id q1mr2038494wix.13.1337350611227; Fri, 18 May 2012 07:16:51 -0700 (PDT) Received: from [192.168.1.105] (93-172-143-98.bb.netvision.net.il. [93.172.143.98]) by mx.google.com with ESMTPS id dg2sm2007095wib.4.2012.05.18.07.16.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 May 2012 07:16:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1457\)) From: Leon Portman In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312A763464D@MCHP058A.global-ad.net> Date: Fri, 18 May 2012 17:16:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <12065B5C-C83E-42F4-B5C7-927EB1A0B210@gmail.com> References: <101C6067BEC68246B0C3F6843BCCC1E312A763464D@MCHP058A.global-ad.net> To: "Hutton, Andrew" X-Mailer: Apple Mail (2.1457) Cc: "siprec@ietf.org" Subject: Re: [siprec] Status of draft-siprec-architecture. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 14:16:52 -0000 Andy Hi I will issue updated version early next week. Regards Leon On May 18, 2012, at 5:14 PM, "Hutton, Andrew" = wrote: > Hi All, >=20 > Following the WGLC and the discussion at IETF83 we have I think to = make one further update to draft-ietf-siprec-architecture before passing = it on to the IESG. >=20 > The mostly editorial comments from Ram and Charles from the following = two e-mail's need to be taken in to account. >=20 > http://www.ietf.org/mail-archive/web/siprec/current/msg03204.html >=20 > http://www.ietf.org/mail-archive/web/siprec/current/msg03210.html >=20 > Section 3.3.2 I think we previously agreed to remove the text = "Possibly using the Join header". >=20 > =46rom discussion at IETF83 Paul Kyzivat suggested that we could = remove section 3.1.3 "A SIP Proxy cannot be a Session Recording Client". = I did not hear any objections to this. >=20 > Also at IET83 we discussed the statement in 3.1.1 regarding the B2BUA = being responsible for honouring the indication from a UA not to record. = Charles suggested that the current wording made it sound mandatory but I = think we are in agreement that we don't want to have to enforce this and = so the wording should be watered down a little bit to say that the = "B2BUA/SRC may honour the indication....". >=20 > Leon, would you be able to update the draft soon? >=20 > We need to update the milestone and I am hoping that getting this = draft to the IESG before the next IETF meeting is a reasonable = objective? >=20 > Regards > Andy >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pravindran@sonusnet.com Fri May 18 07:52: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 184FE21F864C for ; Fri, 18 May 2012 07:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.453 X-Spam-Level: X-Spam-Status: No, score=-6.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 bcClazC6FzIn for ; Fri, 18 May 2012 07:52:57 -0700 (PDT) Received: from na3sys010aog104.obsmtp.com (na3sys010aog104.obsmtp.com [74.125.245.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6D121F864A for ; Fri, 18 May 2012 07:52:57 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob104.postini.com ([74.125.244.12]) with SMTP ID DSNKT7ZiSF47XZkQTtZpo+npamJ49y/mp+7l@postini.com; Fri, 18 May 2012 07:52:57 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 18 May 2012 10:53:13 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Fri, 18 May 2012 20:22:51 +0530 From: "Ravindran, Parthasarathi" To: "Hutton, Andrew" , "siprec@ietf.org" , Leon Portman Thread-Topic: Status of draft-siprec-architecture. Thread-Index: Ac01AIEuOYxaM3nITvCM2WfwZmo2XwABSNmQ Date: Fri, 18 May 2012 14:52:49 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C160356B6@inba-mail01.sonusnet.com> References: <101C6067BEC68246B0C3F6843BCCC1E312A763464D@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312A763464D@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.99] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Status of draft-siprec-architecture. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 14:52:58 -0000 Andy, As per IETF-83 meeting minutes, One more Textual changes on the document na= mely "SRS initiated recording: Wording seems to imply that recording is man= datory, text needs clarification" Thanks Partha >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Hutton, Andrew >Sent: Friday, May 18, 2012 7:44 PM >To: siprec@ietf.org; Leon Portman >Subject: [siprec] Status of draft-siprec-architecture. > >Hi All, > >Following the WGLC and the discussion at IETF83 we have I think to make >one further update to draft-ietf-siprec-architecture before passing it >on to the IESG. > >The mostly editorial comments from Ram and Charles from the following >two e-mail's need to be taken in to account. > >http://www.ietf.org/mail-archive/web/siprec/current/msg03204.html > >http://www.ietf.org/mail-archive/web/siprec/current/msg03210.html > >Section 3.3.2 I think we previously agreed to remove the text "Possibly >using the Join header". > >From discussion at IETF83 Paul Kyzivat suggested that we could remove >section 3.1.3 "A SIP Proxy cannot be a Session Recording Client". I did >not hear any objections to this. > >Also at IET83 we discussed the statement in 3.1.1 regarding the B2BUA >being responsible for honouring the indication from a UA not to record. >Charles suggested that the current wording made it sound mandatory but I >think we are in agreement that we don't want to have to enforce this and >so the wording should be watered down a little bit to say that the >"B2BUA/SRC may honour the indication....". > >Leon, would you be able to update the draft soon? > >We need to update the milestone and I am hoping that getting this draft >to the IESG before the next IETF meeting is a reasonable objective? > >Regards >Andy > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Fri May 18 09:27:30 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A58321F860B for ; Fri, 18 May 2012 09:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 xYSgBh-tvnKb for ; Fri, 18 May 2012 09:27:30 -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 D7D9421F853F for ; Fri, 18 May 2012 09:27:29 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 1D08323F079A for ; Fri, 18 May 2012 18:27:29 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 18 May 2012 18:27:29 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" Date: Fri, 18 May 2012 18:27:27 +0200 Thread-Topic: status of draft-ietf-siprec-protocol Thread-Index: Ac01Ex1EJuZ+fFJ+S7azitFumspJvA== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312A7634687@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] status of draft-ietf-siprec-protocol 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, 18 May 2012 16:27:30 -0000 Hi All, The 04 version has just recently been submitted (http://www.ietf.org/intern= et-drafts/draft-ietf-siprec-protocol-04.txt) and Richard Barnes has agreed = to do a security review of the document. I think we do now need a few other people to do a full review of this docum= ent any volunteers? I will try to do this myself over the next couple of weeks. There is however I believe some minor updates still to do as a result of IE= TF83 discussion (See IETF83 Minutes). Regards Andy From pravindran@sonusnet.com Mon May 21 00:28: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 56FC721F84B4 for ; Mon, 21 May 2012 00:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 MAyXbLuKoOwW for ; Mon, 21 May 2012 00:28:50 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with ESMTP id 9A68121F850C for ; Mon, 21 May 2012 00:28:50 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKT7nusbNbS/KhxMVDU8KdjzpbShLfGdpu@postini.com; Mon, 21 May 2012 00:28:50 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; Mon, 21 May 2012 03:29:08 -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; Mon, 21 May 2012 12:58:44 +0530 From: "Ravindran, Parthasarathi" To: "Hutton, Andrew" , "siprec@ietf.org" Thread-Topic: status of draft-ietf-siprec-protocol Thread-Index: Ac01Ex1EJuZ+fFJ+S7azitFumspJvACD9xYg Date: Mon, 21 May 2012 07:28:42 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C16035874@inba-mail01.sonusnet.com> References: <101C6067BEC68246B0C3F6843BCCC1E312A7634687@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312A7634687@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.99] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] status of draft-ietf-siprec-protocol 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, 21 May 2012 07:28:51 -0000 Andy, Please count me for full review of this document. Thanks Partha >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Hutton, Andrew >Sent: Friday, May 18, 2012 9:57 PM >To: siprec@ietf.org >Subject: [siprec] status of draft-ietf-siprec-protocol > >Hi All, > >The 04 version has just recently been submitted >(http://www.ietf.org/internet-drafts/draft-ietf-siprec-protocol-04.txt) >and Richard Barnes has agreed to do a security review of the document. > >I think we do now need a few other people to do a full review of this >document any volunteers? > >I will try to do this myself over the next couple of weeks. > >There is however I believe some minor updates still to do as a result of >IETF83 discussion (See IETF83 Minutes). > >Regards >Andy >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Mon May 21 05:49: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 B357A21F8495 for ; Mon, 21 May 2012 05:49:59 -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 mLHW6q2XAVoQ for ; Mon, 21 May 2012 05:49:59 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id A3A5C21F848C for ; Mon, 21 May 2012 05:49:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=1302; q=dns/txt; s=iport; t=1337604598; x=1338814198; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=3O6OiupUgKgYLEzTcUiB0yeM+khhZibHndmyX7/1cHw=; b=BmFfkTIYgsJHcaTGuH6Y8uItjyRQj0s+xxrF+B3lAKzw/HShokEBrpOD N2jOgak2YtVeQP5bQSsiyTPDnpIsTDiJNRoAfn8J1lKpI8Ydad6Lg13dH 9KcSiZ26pLM57v6087syEr3WkcZA70w0/8Sfh8uDfHVov9iL4lqNZ6avV 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAJk5uk9Io8UY/2dsb2JhbABEgx2xaoIVAQEBAwEBAQEPAScCATEQBwcIEQQBASguHwkIBgEKCAkZh2cFC58xn16LBYVNA4hAjFuFT4g9gWSCcQ X-IronPort-AV: E=Sophos;i="4.75,631,1330905600"; d="scan'208";a="12647748" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 21 May 2012 12:49:56 +0000 Received: from [10.65.71.50] ([10.65.71.50]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q4LCnjOP017054; Mon, 21 May 2012 12:49:49 GMT User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Mon, 21 May 2012 16:30:54 +0530 From: Ram Mohan R To: "Ravindran, Parthasarathi" , "Hutton, Andrew" , "siprec@ietf.org" Message-ID: Thread-Topic: [siprec] status of draft-ietf-siprec-protocol In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C16035874@inba-mail01.sonusnet.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [siprec] status of draft-ietf-siprec-protocol 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, 21 May 2012 12:49:59 -0000 Andy, I will also review the document. Regards, Ram > On 21/05/12 12:58 PM, "Ravindran, Parthasarathi" > wrote: >Andy, > >Please count me for full review of this document. > >Thanks >Partha > >>-----Original Message----- >>From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >>Of Hutton, Andrew >>Sent: Friday, May 18, 2012 9:57 PM >>To: siprec@ietf.org >>Subject: [siprec] status of draft-ietf-siprec-protocol >> >>Hi All, >> >>The 04 version has just recently been submitted >>(http://www.ietf.org/internet-drafts/draft-ietf-siprec-protocol-04.txt) >>and Richard Barnes has agreed to do a security review of the document. >> >>I think we do now need a few other people to do a full review of this >>document any volunteers? >> >>I will try to do this myself over the next couple of weeks. >> >>There is however I believe some minor updates still to do as a result of >>IETF83 discussion (See IETF83 Minutes). >> >>Regards >>Andy >>_______________________________________________ >>siprec mailing list >>siprec@ietf.org >>https://www.ietf.org/mailman/listinfo/siprec >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec > From DAVE.HIGTON@nice.com Wed May 23 04:07:43 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A2421F85FF for ; Wed, 23 May 2012 04:07:43 -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 0T-ukyZE4AFp for ; Wed, 23 May 2012 04:07:43 -0700 (PDT) Received: from soumd01.eu.nice.com (UKEmail.nice.com [195.166.55.162]) by ietfa.amsl.com (Postfix) with ESMTP id E4FD921F85A2 for ; Wed, 23 May 2012 04:07:42 -0700 (PDT) Received: from mail pickup service by soumd01.eu.nice.com with Microsoft SMTPSVC; Wed, 23 May 2012 12:07:41 +0100 Received: from SOUCAS01.eu.nice.com ([10.1.1.9]) by soumd01.eu.nice.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 May 2012 12:07:40 +0100 Received: from SOUEXC01.eu.nice.com ([fe80::759b:eded:96a6:f00e]) by SOUCAS01.eu.nice.com ([::1]) with mapi; Wed, 23 May 2012 12:07:39 +0100 From: "Dave Higton" To: Date: Wed, 23 May 2012 12:07:38 +0100 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Thread-Topic: draft-ietf-siprec-protocol-04.txt Thread-Index: Ac041EQQC3HvKZD2Tl+Hjyur1nawaQ== Message-ID: <9B0B6FB9606F4D4AB133C5E9A203B6940558E2BF01@SOUEXC01.eu.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 May 2012 11:07:40.0620 (UTC) FILETIME=[450B40C0:01CD38D4] Subject: [siprec] draft-ietf-siprec-protocol-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 11:08:47 -0000 I have a couple of comments: 1) Section 7.1.1.1 "Forwarding Translator" says: "RTCP Receiver Reports = generated by the SRS MUST be forwarded to the relevant UA." This implies that the UA receives an RR for something that it didn't = send. Shouldn't the RR from the SRS be received by the translator, and the = translator send an RR to the UA? In effect, shouldn't the translator = translate the RTCP as well as the RTP, rather than purely forwarding it? = I think each path (UA <-> translator and translator <-> SRS) should be = independent and complete within themselves. A source sends RTP to a = destination; that destination (and no other) should provide the RR, and = the RR should go back to the source of that RTP, not some other source = of a different stream. 2) Section 7.1.1.2. "Transcoding Translator" says: "All RTCP reports = MUST passed by the SRC between the UAs and the SRS, such the UAs and SRS = they are able to detect any SSRC collisions." This is a malformed sentence. I think the equivalent from section = 7.1.1.1 is correct: "All RTCP reports MUST be passed by the SRC between = the UAs and the SRS, such that the UAs and SRS are able to detect any = SSRC collisions." Subject to my comments in point 1, anyway. Dave NICE Systems UK Limited ("NICE") is registered in England under company = number, 3403044. The registered office of NICE is at Tollbar Way, Hedge = End, Southampton, Hampshire SO30 2ZP. Confidentiality: This communication and any attachments are intended for = the above-named persons only and may be confidential and/or legally = privileged. Any opinions expressed in this communication are not = necessarily those of NICE. If this communication has come to you in = error you must take no action based on it, nor must you copy or show it = to anyone; please delete/destroy and inform the sender by e-mail = immediately. Monitoring: NICE may monitor incoming and outgoing e-mails. Viruses: Although we have taken steps toward ensuring that this e-mail = and attachments are free from any virus, we advise that in keeping with = good computing practice the recipient should ensure they are actually = virus free. From pravindran@sonusnet.com Wed May 23 07:10:39 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 5F73421F8694 for ; Wed, 23 May 2012 07:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 TvWKHCw6WeSJ for ; Wed, 23 May 2012 07:10:38 -0700 (PDT) Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC7421F8692 for ; Wed, 23 May 2012 07:10:37 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKT7zv3NJqFIk5BK6QNX7ZnSO55grfNiew@postini.com; Wed, 23 May 2012 07:10:37 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 23 May 2012 10:10:56 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Wed, 23 May 2012 19:40:31 +0530 From: "Ravindran, Parthasarathi" To: Dave Higton , "siprec@ietf.org" Thread-Topic: draft-ietf-siprec-protocol-04.txt Thread-Index: Ac041EQQC3HvKZD2Tl+Hjyur1nawaQAGMRPA Date: Wed, 23 May 2012 14:10:30 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C1603660A@inba-mail01.sonusnet.com> References: <9B0B6FB9606F4D4AB133C5E9A203B6940558E2BF01@SOUEXC01.eu.nice.com> In-Reply-To: <9B0B6FB9606F4D4AB133C5E9A203B6940558E2BF01@SOUEXC01.eu.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.99] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] draft-ietf-siprec-protocol-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 14:10:39 -0000 Dave, In case of forwarding translator, SRC is not the source of the RTP and SRC = does not manipulate RTP data format. So, I'm not seeing issue in forwarding= RTCP packet to RTP Endpoint as per Sec 7.2 of RFC 3550.=20 Thanks Partha >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Dave Higton >Sent: Wednesday, May 23, 2012 4:38 PM >To: siprec@ietf.org >Subject: [siprec] draft-ietf-siprec-protocol-04.txt > >I have a couple of comments: > >1) Section 7.1.1.1 "Forwarding Translator" says: "RTCP Receiver Reports >generated by the SRS MUST be forwarded to the relevant UA." > >This implies that the UA receives an RR for something that it didn't >send. > >Shouldn't the RR from the SRS be received by the translator, and the >translator send an RR to the UA? In effect, shouldn't the translator >translate the RTCP as well as the RTP, rather than purely forwarding it? >I think each path (UA <-> translator and translator <-> SRS) should be >independent and complete within themselves. A source sends RTP to a >destination; that destination (and no other) should provide the RR, and >the RR should go back to the source of that RTP, not some other source >of a different stream. > >2) Section 7.1.1.2. "Transcoding Translator" says: "All RTCP reports >MUST passed by the SRC between the UAs and the SRS, such the UAs and SRS >they are able to detect any SSRC collisions." > >This is a malformed sentence. I think the equivalent from section >7.1.1.1 is correct: "All RTCP reports MUST be passed by the SRC between >the UAs and the SRS, such that the UAs and SRS are able to detect any >SSRC collisions." > >Subject to my comments in point 1, anyway. > >Dave > > > >NICE Systems UK Limited ("NICE") is registered in England under company >number, 3403044. The registered office of NICE is at Tollbar Way, Hedge >End, Southampton, Hampshire SO30 2ZP. > >Confidentiality: This communication and any attachments are intended for >the above-named persons only and may be confidential and/or legally >privileged. Any opinions expressed in this communication are not >necessarily those of NICE. If this communication has come to you in >error you must take no action based on it, nor must you copy or show it >to anyone; please delete/destroy and inform the sender by e-mail >immediately. > >Monitoring: NICE may monitor incoming and outgoing e-mails. > >Viruses: Although we have taken steps toward ensuring that this e-mail >and attachments are free from any virus, we advise that in keeping with >good computing practice the recipient should ensure they are actually >virus free. >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From DAVE.HIGTON@nice.com Wed May 23 07:15:57 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D5521F86E4 for ; Wed, 23 May 2012 07:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 EYqiosdRB+0z for ; Wed, 23 May 2012 07:15:56 -0700 (PDT) Received: from soumd01.eu.nice.com (UKEmail.nice.com [195.166.55.162]) by ietfa.amsl.com (Postfix) with ESMTP id 12AB221F8694 for ; Wed, 23 May 2012 07:15:55 -0700 (PDT) Received: from mail pickup service by soumd01.eu.nice.com with Microsoft SMTPSVC; Wed, 23 May 2012 15:15:54 +0100 Received: from SOUCAS02.eu.nice.com ([10.1.1.10]) by soumd01.eu.nice.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 May 2012 15:15:53 +0100 Received: from SOUEXC01.eu.nice.com ([fe80::759b:eded:96a6:f00e]) by SOUCAS02.eu.nice.com ([::1]) with mapi; Wed, 23 May 2012 15:15:53 +0100 From: "Dave Higton" To: "Ravindran, Parthasarathi" , Date: Wed, 23 May 2012 15:15:51 +0100 Content-Class: urn:content-classes:message Importance: normal Thread-Topic: draft-ietf-siprec-protocol-04.txt Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Thread-Index: Ac041EQQC3HvKZD2Tl+Hjyur1nawaQAGMRPAAAA9uaA= Message-ID: <9B0B6FB9606F4D4AB133C5E9A203B6940558E2C00C@SOUEXC01.eu.nice.com> References: <9B0B6FB9606F4D4AB133C5E9A203B6940558E2BF01@SOUEXC01.eu.nice.com> <387F9047F55E8C42850AD6B3A7A03C6C1603660A@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C1603660A@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 May 2012 14:15:53.0823 (UTC) FILETIME=[905146F0:01CD38EE] Subject: Re: [siprec] draft-ietf-siprec-protocol-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 14:15:57 -0000 Surely the whole point of a translator is that the two RTP streams (the = one into the translator and the one out of the translator) are = different, and have different destinations. It seems to me, therefore, = that the destination of each stream should send RRs to the source of = that stream. It seems bizarre to me that A should send a stream to B, but then get a = receiver report from C for a different stream. Dave > -----Original Message----- > From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > Sent: 2012 May 23 15:11 > To: Dave Higton; siprec@ietf.org > Subject: RE: draft-ietf-siprec-protocol-04.txt >=20 > Dave, >=20 > In case of forwarding translator, SRC is not the source of the RTP and > SRC does not manipulate RTP data format. So, I'm not seeing issue in > forwarding RTCP packet to RTP Endpoint as per Sec 7.2 of RFC 3550. >=20 > Thanks > Partha >=20 > >-----Original Message----- > >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > >Of Dave Higton > >Sent: Wednesday, May 23, 2012 4:38 PM > >To: siprec@ietf.org > >Subject: [siprec] draft-ietf-siprec-protocol-04.txt > > > >I have a couple of comments: > > > >1) Section 7.1.1.1 "Forwarding Translator" says: "RTCP Receiver > Reports > >generated by the SRS MUST be forwarded to the relevant UA." > > > >This implies that the UA receives an RR for something that it didn't > >send. > > > >Shouldn't the RR from the SRS be received by the translator, and the > >translator send an RR to the UA? In effect, shouldn't the translator > >translate the RTCP as well as the RTP, rather than purely forwarding > it? > >I think each path (UA <-> translator and translator <-> SRS) should = be > >independent and complete within themselves. A source sends RTP to a > >destination; that destination (and no other) should provide the RR, > and > >the RR should go back to the source of that RTP, not some other = source > >of a different stream. > > > >2) Section 7.1.1.2. "Transcoding Translator" says: "All RTCP reports > >MUST passed by the SRC between the UAs and the SRS, such the UAs and > SRS > >they are able to detect any SSRC collisions." > > > >This is a malformed sentence. I think the equivalent from section > >7.1.1.1 is correct: "All RTCP reports MUST be passed by the SRC > between > >the UAs and the SRS, such that the UAs and SRS are able to detect any > >SSRC collisions." > > > >Subject to my comments in point 1, anyway. > > > >Dave NICE Systems UK Limited ("NICE") is registered in England under company = number, 3403044. The registered office of NICE is at Tollbar Way, Hedge = End, Southampton, Hampshire SO30 2ZP. Confidentiality: This communication and any attachments are intended for = the above-named persons only and may be confidential and/or legally = privileged. Any opinions expressed in this communication are not = necessarily those of NICE. If this communication has come to you in = error you must take no action based on it, nor must you copy or show it = to anyone; please delete/destroy and inform the sender by e-mail = immediately. Monitoring: NICE may monitor incoming and outgoing e-mails. Viruses: Although we have taken steps toward ensuring that this e-mail = and attachments are free from any virus, we advise that in keeping with = good computing practice the recipient should ensure they are actually = virus free. From pravindran@sonusnet.com Wed May 23 19:02: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 A4AF811E80AF for ; Wed, 23 May 2012 19:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 7kjtB+2DBI0e for ; Wed, 23 May 2012 19:02:28 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with ESMTP id 94F9811E8072 for ; Wed, 23 May 2012 19:02:27 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKT72Wsosrs+P7JVWwPe5zUMFx8R7qWCrf@postini.com; Wed, 23 May 2012 19:02:27 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 23 May 2012 22:02:47 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Thu, 24 May 2012 07:32:21 +0530 From: "Ravindran, Parthasarathi" To: Dave Higton , "siprec@ietf.org" Thread-Topic: draft-ietf-siprec-protocol-04.txt Thread-Index: Ac041EQQC3HvKZD2Tl+Hjyur1nawaQAGMRPAAAA9uaAAGA9WcA== Date: Thu, 24 May 2012 02:02:20 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C160366EF@inba-mail01.sonusnet.com> References: <9B0B6FB9606F4D4AB133C5E9A203B6940558E2BF01@SOUEXC01.eu.nice.com> <387F9047F55E8C42850AD6B3A7A03C6C1603660A@inba-mail01.sonusnet.com> <9B0B6FB9606F4D4AB133C5E9A203B6940558E2C00C@SOUEXC01.eu.nice.com> In-Reply-To: <9B0B6FB9606F4D4AB133C5E9A203B6940558E2C00C@SOUEXC01.eu.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] draft-ietf-siprec-protocol-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 02:02:28 -0000 Dave, Translator may be between unicast to multicast IP address as well and=20 in such translator, RTCP from multicast endpoints are not mandated to=20 be dropped by translator. RFC snippet in Sec 7.2 of RFC3550 is as=20 follows: " A translator that does not modify the data packets, for example one that just replicates between a multicast address and a unicast address, MAY simply forward RTCP packets unmodified as well." In fact, the basic SIP session (signaling) perspective in=20 RTP translator, A send stream to B but receive RTCP from C which is the=20 actual destination. In SIPREC scenario, A send stream to B but receive=20 RTCP report from C (destination) and D (recorder). Thanks Partha >-----Original Message----- >From: Dave Higton [mailto:DAVE.HIGTON@nice.com] >Sent: Wednesday, May 23, 2012 7:46 PM >To: Ravindran, Parthasarathi; siprec@ietf.org >Subject: RE: draft-ietf-siprec-protocol-04.txt > >Surely the whole point of a translator is that the two RTP streams (the >one into the translator and the one out of the translator) are >different, and have different destinations. It seems to me, therefore, >that the destination of each stream should send RRs to the source of >that stream. > >It seems bizarre to me that A should send a stream to B, but then get a >receiver report from C for a different stream. > >Dave > >> -----Original Message----- >> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >> Sent: 2012 May 23 15:11 >> To: Dave Higton; siprec@ietf.org >> Subject: RE: draft-ietf-siprec-protocol-04.txt >> >> Dave, >> >> In case of forwarding translator, SRC is not the source of the RTP and >> SRC does not manipulate RTP data format. So, I'm not seeing issue in >> forwarding RTCP packet to RTP Endpoint as per Sec 7.2 of RFC 3550. >> >> Thanks >> Partha >> >> >-----Original Message----- >> >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf >> >Of Dave Higton >> >Sent: Wednesday, May 23, 2012 4:38 PM >> >To: siprec@ietf.org >> >Subject: [siprec] draft-ietf-siprec-protocol-04.txt >> > >> >I have a couple of comments: >> > >> >1) Section 7.1.1.1 "Forwarding Translator" says: "RTCP Receiver >> Reports >> >generated by the SRS MUST be forwarded to the relevant UA." >> > >> >This implies that the UA receives an RR for something that it didn't >> >send. >> > >> >Shouldn't the RR from the SRS be received by the translator, and the >> >translator send an RR to the UA? In effect, shouldn't the translator >> >translate the RTCP as well as the RTP, rather than purely forwarding >> it? >> >I think each path (UA <-> translator and translator <-> SRS) should >> >be independent and complete within themselves. A source sends RTP to >> >a destination; that destination (and no other) should provide the RR, >> and >> >the RR should go back to the source of that RTP, not some other >> >source of a different stream. >> > >> >2) Section 7.1.1.2. "Transcoding Translator" says: "All RTCP reports >> >MUST passed by the SRC between the UAs and the SRS, such the UAs and >> SRS >> >they are able to detect any SSRC collisions." >> > >> >This is a malformed sentence. I think the equivalent from section >> >7.1.1.1 is correct: "All RTCP reports MUST be passed by the SRC >> between >> >the UAs and the SRS, such that the UAs and SRS are able to detect any >> >SSRC collisions." >> > >> >Subject to my comments in point 1, anyway. >> > >> >Dave > > >NICE Systems UK Limited ("NICE") is registered in England under company >number, 3403044. The registered office of NICE is at Tollbar Way, Hedge >End, Southampton, Hampshire SO30 2ZP. > >Confidentiality: This communication and any attachments are intended for >the above-named persons only and may be confidential and/or legally >privileged. Any opinions expressed in this communication are not >necessarily those of NICE. If this communication has come to you in >error you must take no action based on it, nor must you copy or show it >to anyone; please delete/destroy and inform the sender by e-mail >immediately. > >Monitoring: NICE may monitor incoming and outgoing e-mails. > >Viruses: Although we have taken steps toward ensuring that this e-mail >and attachments are free from any virus, we advise that in keeping with >good computing practice the recipient should ensure they are actually >virus free. From eckelcu@cisco.com Thu May 24 09:32:45 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 69E1221F8631 for ; Thu, 24 May 2012 09:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 TWJLcs5Xw4Wy for ; Thu, 24 May 2012 09:32:44 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6342521F856F for ; Thu, 24 May 2012 09:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=4612; q=dns/txt; s=iport; t=1337877164; x=1339086764; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=N9u0GB+Ke6E/4BLk5c321bZ9S2Mh+xT6KuJZQqF8EuA=; b=HbUUxbhBJ4Fsz9fwsM+0Bn/Xd01Mq1GfmQV65B9calc8WurMawigpYDU dcDgJYvzeckqsedrWmpvK2oKFd8SOK0DgGOst/VXfI96cfl5H3vzxcdu/ 4P8uFgBR4Tx+JltiCAxkTubO0e0EArk/KYGabDwaM0jb6i4inOuV8sZ/8 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAE9ivk+rRDoJ/2dsb2JhbABDtGSBB4IVAQEBBAEBAQ8BFAkKGhoXBAIBCBEEAQELBhcBBgEmHwkIAQEEARIIGodqAQubUqAABIp/FAaEJmADiD+aZYFkgwqBNgcC X-IronPort-AV: E=Sophos;i="4.75,652,1330905600"; d="scan'208";a="43673502" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 24 May 2012 16:32:40 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q4OGWeJI003951; Thu, 24 May 2012 16:32:40 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 May 2012 09:32:40 -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, 24 May 2012 09:32:40 -0700 Message-ID: In-Reply-To: <9B0B6FB9606F4D4AB133C5E9A203B6940558E2C00C@SOUEXC01.eu.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] draft-ietf-siprec-protocol-04.txt Thread-Index: Ac041EQQC3HvKZD2Tl+Hjyur1nawaQAGMRPAAAA9uaAANtZakA== References: <9B0B6FB9606F4D4AB133C5E9A203B6940558E2BF01@SOUEXC01.eu.nice.com><387F9047F55E8C42850AD6B3A7A03C6C1603660A@inba-mail01.sonusnet.com> <9B0B6FB9606F4D4AB133C5E9A203B6940558E2C00C@SOUEXC01.eu.nice.com> From: "Charles Eckel (eckelcu)" To: "Dave Higton" , "Ravindran, Parthasarathi" , X-OriginalArrivalTime: 24 May 2012 16:32:40.0461 (UTC) FILETIME=[D6449BD0:01CD39CA] Subject: Re: [siprec] draft-ietf-siprec-protocol-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 16:32:45 -0000 Hi Dave, First, thanks for reviewing the draft and for catching the typo in 7.1.1.2. The word "be" was accidentally omitted. I will see to it that the next rev of draft is updated as you suggested. As for your concern regarding the functionality of the RTP translator, it seems your expectations are more in line with an SRC acting as an RTP endpoint, as discussed in section 7.1.3. This is a perfectly acceptable model. Please have a look at that section and let me know if it aligns better with your expectations. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Dave Higton > Sent: Wednesday, May 23, 2012 7:16 AM > To: Ravindran, Parthasarathi; siprec@ietf.org > Subject: Re: [siprec] draft-ietf-siprec-protocol-04.txt >=20 > Surely the whole point of a translator is that the two RTP streams (the > one into the translator and the one out of the translator) are > different, and have different destinations. It seems to me, therefore, > that the destination of each stream should send RRs to the source of > that stream. >=20 > It seems bizarre to me that A should send a stream to B, but then get a > receiver report from C for a different stream. >=20 > Dave >=20 > > -----Original Message----- > > From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > > Sent: 2012 May 23 15:11 > > To: Dave Higton; siprec@ietf.org > > Subject: RE: draft-ietf-siprec-protocol-04.txt > > > > Dave, > > > > In case of forwarding translator, SRC is not the source of the RTP > and > > SRC does not manipulate RTP data format. So, I'm not seeing issue in > > forwarding RTCP packet to RTP Endpoint as per Sec 7.2 of RFC 3550. > > > > Thanks > > Partha > > > > >-----Original Message----- > > >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf > > >Of Dave Higton > > >Sent: Wednesday, May 23, 2012 4:38 PM > > >To: siprec@ietf.org > > >Subject: [siprec] draft-ietf-siprec-protocol-04.txt > > > > > >I have a couple of comments: > > > > > >1) Section 7.1.1.1 "Forwarding Translator" says: "RTCP Receiver > > Reports > > >generated by the SRS MUST be forwarded to the relevant UA." > > > > > >This implies that the UA receives an RR for something that it didn't > > >send. > > > > > >Shouldn't the RR from the SRS be received by the translator, and the > > >translator send an RR to the UA? In effect, shouldn't the > translator > > >translate the RTCP as well as the RTP, rather than purely forwarding > > it? > > >I think each path (UA <-> translator and translator <-> SRS) should > be > > >independent and complete within themselves. A source sends RTP to a > > >destination; that destination (and no other) should provide the RR, > > and > > >the RR should go back to the source of that RTP, not some other > source > > >of a different stream. > > > > > >2) Section 7.1.1.2. "Transcoding Translator" says: "All RTCP reports > > >MUST passed by the SRC between the UAs and the SRS, such the UAs and > > SRS > > >they are able to detect any SSRC collisions." > > > > > >This is a malformed sentence. I think the equivalent from section > > >7.1.1.1 is correct: "All RTCP reports MUST be passed by the SRC > > between > > >the UAs and the SRS, such that the UAs and SRS are able to detect > any > > >SSRC collisions." > > > > > >Subject to my comments in point 1, anyway. > > > > > >Dave >=20 >=20 > NICE Systems UK Limited ("NICE") is registered in England under company > number, 3403044. The registered office of NICE is at Tollbar Way, Hedge > End, Southampton, Hampshire SO30 2ZP. >=20 > Confidentiality: This communication and any attachments are intended > for the above-named persons only and may be confidential and/or legally > privileged. Any opinions expressed in this communication are not > necessarily those of NICE. If this communication has come to you in > error you must take no action based on it, nor must you copy or show it > to anyone; please delete/destroy and inform the sender by e-mail > immediately. >=20 > Monitoring: NICE may monitor incoming and outgoing e-mails. >=20 > Viruses: Although we have taken steps toward ensuring that this e-mail > and attachments are free from any virus, we advise that in keeping with > good computing practice the recipient should ensure they are actually > virus free. > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Mon May 28 07:15: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 3606121F853D for ; Mon, 28 May 2012 07:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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] 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 e79hzMvPGph7 for ; Mon, 28 May 2012 07:15:46 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id E42DA21F8539 for ; Mon, 28 May 2012 07:15:45 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id EE7381EB84B9; Mon, 28 May 2012 16:15:44 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.222]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.01.0339.001; Mon, 28 May 2012 16:15:44 +0200 From: "Hutton, Andrew" To: "Ravindran, Parthasarathi" , "john.2.stafford@bt.com" Thread-Topic: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. Thread-Index: AQHNDPHbKGqRGqQpE0uaR07g0+NKr5aANujQgADFHNKAQLr/EP//rzSAgAHcSUCAACRbR///8r+AgAXAYoCAAF0f0IAC2bZggBNHBaA= Date: Mon, 28 May 2012 14:15:43 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF012140@MCHP04MSX.global-ad.net> References: , <4FAC1EDD.8030800@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C16034636@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C16034E25@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C16034E25@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.27.249.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 14:15:48 -0000 Hi All, I just want to make sure I understand the results of this discussion and wh= ether we have consensus. I am assuming we have consensus to move to using "stream_id" rather than "i= d" 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 t= o a single RS stream then the following seems to be what we have settled on= . 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: =09 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. >=20 > Hi all, >=20 > 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. >=20 > Thanks > Partha >=20 > >-----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"> > >>>>>> >>>>>> 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 > >>>>>> [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 From andrew.hutton@siemens-enterprise.com Mon May 28 07:19: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 21F0321F853D for ; Mon, 28 May 2012 07:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 McNyDnzCLemk for ; Mon, 28 May 2012 07:19:03 -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 31C9421F8539 for ; Mon, 28 May 2012 07:19:03 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 97CA91EB84C3 for ; Mon, 28 May 2012 16:19:02 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.222]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.01.0339.001; Mon, 28 May 2012 16:19:02 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: SIPREC Session at IETF84 Thread-Index: Ac083NRdAiOubG7rQOCRlqMA/qc7Kw== Date: Mon, 28 May 2012 14:19:01 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF012163@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.249.76] 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, 28 May 2012 14:19:04 -0000 Hi All, Yes it is time to think about IETF84 already as we have to book the session= . I have gone ahead and asked for the usual 2 hour session in the expectation= that we will get lots of review comments for the protocol and architecture= draft. If we don't see many comments over the next month then maybe we will reduce= the session to 1 hour. Regards Andy (SIPREC Co-Chair). From pravindran@sonusnet.com Mon May 28 10:15:15 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC2521F8566 for ; Mon, 28 May 2012 10:15:15 -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 cMpwhnymeNbI for ; Mon, 28 May 2012 10:15:14 -0700 (PDT) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF1221F858E for ; Mon, 28 May 2012 10:15:12 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKT8OyoALcqYD/Qt55Cj5QhRXJzwBKXW2M@postini.com; Mon, 28 May 2012 10:15:13 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 28 May 2012 13:15:35 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Mon, 28 May 2012 22:45:06 +0530 From: "Ravindran, Parthasarathi" To: "Hutton, Andrew" , "john.2.stafford@bt.com" Thread-Topic: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. Thread-Index: AQHNDPHbKGqRGqQpE0uaR07g0+NKr5aANujQgADFHNKAQLr/EP//rzSAgAHcSUCAACRbR///8r+AgAXAYoCAAF0f0IAC2bZggBNHBaCAADQIYA== Date: Mon, 28 May 2012 17:15:05 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C1603732F@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> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF012140@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] 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: Mon, 28 May 2012 17:15:16 -0000 Andy, Recording multiple m line in CS has to be represented as follows: The reason for this approach in XML is due to the metadata model constraint= s and the exact details are as follows: 1) Mapping of each individual label (SDP "m" line) to single stream by whic= h participantstream's attributes will explain about the stream correctly. S= ay video label attribute is added in the stream element during mid-dialog w= hereas the session is established with audio label & stream, here video lab= el association time is different from audio label association time. =20 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= ,=20 1) It is impossible to deduce the association and disassociation time of th= e individual label or SDP "m" line=20 2) It is possible to have the wrong information like indicate one of the st= ream in "recv" association whereas other stream is in "send" association (H= ypothetical scenario). So, stream XML element has to have single label attribute within itself.=20 Thanks Partha =20 >-----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"> >> >>>>>> > >>>>>> 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 >> >>>>>> [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 From andrew.hutton@siemens-enterprise.com Tue May 29 02:57: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 CDBEE21F8776 for ; Tue, 29 May 2012 02:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtWOK7FFYsrA for ; Tue, 29 May 2012 02:57:04 -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 A8BEA21F8762 for ; Tue, 29 May 2012 02:57:03 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 2A8971EB84A0; Tue, 29 May 2012 11:57:02 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.222]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.01.0339.001; Tue, 29 May 2012 11:57:01 +0200 From: "Hutton, Andrew" To: "Ravindran, Parthasarathi" , "john.2.stafford@bt.com" Thread-Topic: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. Thread-Index: AQHNDPHbKGqRGqQpE0uaR07g0+NKr5aANujQgADFHNKAQLr/EP//rzSAgAHcSUCAACRbR///8r+AgAXAYoCAAF0f0IAC2bZggBNHBaCAADQIYIABFw2w Date: Tue, 29 May 2012 09:57:01 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF012A04@MCHP04MSX.global-ad.net> 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> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C1603732F@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.27.249.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 09:57:05 -0000 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 duplicate= d 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. >=20 > Andy, >=20 > Recording multiple m line in CS has to be represented as follows: >=20 > session_id=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> > > > session_id=3D"zzlafnvvjlCHllaHF6mn8kkSS=3D=3D"> > > >=20 > The reason for this approach in XML is due to the metadata model > constraints and the exact details are as follows: >=20 > 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. >=20 > 2) Partial update for each stream independently provide more > flexibility. (Add & Remove stream without impacting any other stream). >=20 > In case of multiple label exists within single stream as shown in your > mail, >=20 > 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). >=20 > So, stream XML element has to have single label attribute within > itself. >=20 > Thanks > Partha >=20 > >-----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 singl= e > >> >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"> >> >>>>>> 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 From pravindran@sonusnet.com Wed May 30 03:49: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 391A321F86E1 for ; Wed, 30 May 2012 03:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMgyAtlTgRKv for ; Wed, 30 May 2012 03:48:58 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with ESMTP id 9A65821F867E for ; Wed, 30 May 2012 03:48:57 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKT8X7Gd+67YmCzPTWDqJqJ7o3LQ328bRJ@postini.com; Wed, 30 May 2012 03:48:57 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 30 May 2012 06:49:21 -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, 30 May 2012 16:18:50 +0530 From: "Ravindran, Parthasarathi" To: "Hutton, Andrew" , "john.2.stafford@bt.com" Thread-Topic: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. Thread-Index: AQHNDPHbKGqRGqQpE0uaR07g0+NKr5aANujQgADFHNKAQLr/EP//rzSAgAHcSUCAACRbR///8r+AgAXAYoCAAF0f0IAC2bZggBNHBaCAADQIYIABFw2wgAGkwDA= Date: Wed, 30 May 2012 10:48:49 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C160389A1@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> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF012A04@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 10:49:00 -0000 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. Multi= ple label in "stream" element does not indicate the duplication of the CS s= tream automatically. Apart from this, There is a need of explicit grouping = mechanism to say that two stream are duplicate of each other.=20 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 sing= le >> >> >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"> > >> >>>>>> 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 From andrew.hutton@siemens-enterprise.com Wed May 30 04:21: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 0E3EB21F8615 for ; Wed, 30 May 2012 04:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=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 O67VWRf8F8hb for ; Wed, 30 May 2012 04:21:13 -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 E361621F86D6 for ; Wed, 30 May 2012 04:21:12 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id E89AF23F0574; Wed, 30 May 2012 13:21:11 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.222]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.01.0339.001; Wed, 30 May 2012 13:21:11 +0200 From: "Hutton, Andrew" To: "Miguel A. Garcia" Thread-Topic: SDP Comments to draft-ietf-siprec-protocol-00 Thread-Index: Acxx8tLJHuCEmImhT1Gldr8fzviEiTMW8mbQ Date: Wed, 30 May 2012 11:21:10 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF013D86@MCHP04MSX.global-ad.net> References: <4E6F1A63.1000202@ericsson.com> In-Reply-To: <4E6F1A63.1000202@ericsson.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: "fandreas@cisco.com" , "siprec@ietf.org" Subject: Re: [siprec] SDP Comments to draft-ietf-siprec-protocol-00 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, 30 May 2012 11:21:14 -0000 Hi Miguel, I checked whether your comments had been taken care of in the latest versio= n of draft-ietf-siprec-protocol and found that mostly they have apart from = a couple of minor omissions. See the text below for my analysis. Regarding getting the SDP directorate to review the draft then given your p= revious review I think we can wait until the draft is at WGLC before we ask= for a review by the SDP directorate. This I hope will not be long probabl= y following Vancouver. Henry, Could you please take care of the outstanding issues below as you ha= ve the pen. Regards Andy > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: 13 September 2011 09:55 > To: leon.portman@nice.com; henry.lum@genesyslab.com; > alan.b.johnston@gmail.com; Hutton, Andrew; siprec@ietf.org; mmusic > Cc: Elwell, John; Brian Rosen > Subject: SDP Comments to draft-ietf-siprec-protocol-00 >=20 > Hi, >=20 > here are some comments to the SDP in draft-ietf-siprec-protocol-00 >=20 > - Section 5.3. I found a few "must" and "should" in lowercase. I wonder > whether these should be written normatively (uppercase) or is there a > reason for not doing it, in which case, I would recommend to go around > the lowercase terms to avoid confusion. Done >=20 > - Section 5.3, third paragraph: the text is written around the format > (a=3Dsendonly), but I will instead put the focus on the semantics. For > example, I would write: >=20 > Since the SRC does not expect to receive media from the SRS, the > SRC > will typically set each media stream of the SDP offer to only send > media, > by qualifying them with the a=3Dsendonly attribute. Conversely, as the > SRS > only receives RTP streams from SRCs, the SDP answer will normally set > each media stream to only receive media, by setting them with the > a=3Drecvonly attribute, according to the procedures of RFC 3264 > [RFC3264]. Partly Done - The SDP answer part being set to a=3Drecvonly is not in the c= urrent draft and could be added. >=20 > - Section 5.3, fourth paragraph. As a matter of personal taste, I > prefer > that actions are attributed to either the SRC or the SRS, but not to > the > "SDP" (which is not an entity). For example, the sentence "the SDP must > provide a label..." should be restated in terms of the "the SRC MUST > include a label *attribute* (a=3Dlabel) in each media stream of the > SDP"... Done >=20 > Also, in this fourth paragraph in Section 5.3, avoid the future tense, > unless you really want to describe an action that will take a later > time: > "... will be used ..." Done >=20 > - Figure 4 in Section 5.3: the "o=3D" line is incorrect, due to sess-id > and > sess-version are set to 0. Also, the selected IP address is not being > according to RFC 5737. Use this one instead: >=20 >=20 > o=3DSRS 2890844526 2890844526 IN IP4 198.51.100.1 Done >=20 > - Figure 4 in Section 5.3: the "s=3D" line is incorrect according to RFC > 3264. Use an white space or dash character instead: >=20 > s=3D- Done >=20 > - Figure 4 in Section 5.3: the "c=3D" line is incorrect due to the IP > address not being according to RFC 5737. Use this one instead (should > be > the same IP address as in the o=3D line). >=20 > c=3DIN IP4 198.51.100.1 Done >=20 > - Figure 4 in Section 5.3: all the m=3D lines are incorrect. All the > lines > should indicate an even port number for RTP, implicitly indicating that > the consecutive port number is used for RTCP. Additionally, two lines > referring to the H264 codec indicate that the stream is of type > "audio", > which is incorrect. Use the following "m=3D" lines (in order). >=20 > m=3Daudio 12240 RTP/AVP 0 4 8 > m=3Dvideo 22456 RTP/AVP 98 > m=3Daudio 12242 RTP/AVP 0 4 8 > m=3Dvideo 22458 RTP/AVP 98 The 4th m-line still incorrectly indicates it is audio - Needs to be fixed. >=20 > - Figure 4 in Section 5.3. Use a correct a=3Dfmtp line, for example: >=20 > a=3Dfmtp:98 profile-level-id=3D42A01E; > sprop-parameter-sets=3DZ0IACpZTBYmI,aMljiA=3D=3D Done. >=20 >=20 > - Section 5.3, 5th and 6th paragraphs: The text should be stated in > terms > of SDP offer/answer (we are in Section 5.3, which is "SDP handling"), > and > a reference to RFC 3264 should be added. Therefore: >=20 > To remove a recorded media stream from the recording session, the > SRC > sends a new SDP offer where the port of the media stream to be > removed is set to zero, according to the procedures in RFC 3264 > [RFC3264]. >=20 > To add a new media stream to the recording session, the SRC sends a > new SDP offer adding a new media stream description in an m=3D line, > according to the procedures in RFC 3264 [RFC3264]. Done=20 >=20 > - Section 5.3, 7th paragraph should also be drafted in terms of SDP > O/A. >=20 > - Figure 6 in Section 5.4, use this SDP instead: >=20 > v=3D0 > o=3DSRS 2890844526 2890844526 IN IP4 198.51.100.1 > s=3D- > c=3DIN IP4 198.51.100.1 > t=3D0 0 > m=3Daudio 12240 RTP/AVP 0 4 8 > a=3Dsendonly > a=3Dlabel:1 >=20 Done - The SDP example has been removed. > - Section 6.2.1. The syntax is not correct. You should start by > extending > the "attribute" production in SDP, for example: >=20 > attribute /=3D record-attr > ; attribute defined in RFC 4566 > record-attr =3D "record:" indication > indication =3D "on" / "off" / "paused" Done - now section 10.2.1 - But also applies to the recordpref-attr in what= is now 10.1.1 so this needs to be fixed. >=20 > - Section 6.2.2. For discussion... Do you really need two attributes, > "record" and "recordpref"? I believe both could be integrated into a > single attribute. For example, you could have the a=3Drecord attribute > with > the two values, one for the current status, and one of the current > preference. >=20 Done - Clarified on mailing list that we do need both. > - Section 7.1. Although this is not related to SDP, in this paragraph > you > need to specify the registry where you want to register the new option > tags. I believe it is the Session Initiation Protocol Parameters > registry. >=20 > - Section 7.5.1 and 7.5.2. The registration lacks contact name, email > address, and telephone number, according to the requirements in RFC > 4566. >=20 Contact names and e-mail address is now included. RFC 4566 requires a telep= hone number but personally I think this is not desirable due to privacy iss= ues. >=20 > /Miguel > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain From andrew.hutton@siemens-enterprise.com Wed May 30 05:07:11 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 66A2421F8710 for ; Wed, 30 May 2012 05:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[AWL=-0.386, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWkTh6EP85Hp for ; Wed, 30 May 2012 05:07:09 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id F263F21F86A1 for ; Wed, 30 May 2012 05:07:08 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 163AB23F03F0; Wed, 30 May 2012 14:07:08 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.222]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.01.0339.001; Wed, 30 May 2012 14:07:07 +0200 From: "Hutton, Andrew" To: "Ravindran, Parthasarathi" Thread-Topic: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. Thread-Index: AQHNDPHbKGqRGqQpE0uaR07g0+NKr5aANujQgADFHNKAQLr/EP//rzSAgAHcSUCAACRbR///8r+AgAXAYoCAAF0f0IAC2bZggBNHBaCAADQIYIABFw2wgAGkwDCAABa4gA== Date: Wed, 30 May 2012 12:07:07 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF013E3F@MCHP04MSX.global-ad.net> 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> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C160389A1@inba-mail01.sonusnet.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] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 12:07:11 -0000 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. >=20 > Hi Andy, >=20 > 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. >=20 > Thanks > Partha >=20 > >-----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"> >> >> >>>>>> 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 From Leon.Portman@nice.com Wed May 30 05:38: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 78A6221F8687 for ; Wed, 30 May 2012 05:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=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 qFOb99+crHjS for ; Wed, 30 May 2012 05:38:56 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id DC1D621F8644 for ; Wed, 30 May 2012 05:38:54 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Wed, 30 May 2012 15:38:47 +0300 From: Leon Portman To: "siprec@ietf.org" Date: Wed, 30 May 2012 15:38:46 +0300 Thread-Topic: [siprec] Updated architecture draft after WGLC comments Thread-Index: Ac0+XcX0y87/u0ClSeq56ayEc5dcxg== Message-ID: <07465C1D981ABC41A344374066AE1A2C3A7AEB818B@TLVMBX01.nice.com> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: multipart/mixed; boundary="_004_07465C1D981ABC41A344374066AE1A2C3A7AEB818BTLVMBX01nicec_" MIME-Version: 1.0 Subject: [siprec] Updated architecture draft after WGLC comments 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, 30 May 2012 12:38:58 -0000 --_004_07465C1D981ABC41A344374066AE1A2C3A7AEB818BTLVMBX01nicec_ Content-Type: multipart/alternative; boundary="_000_07465C1D981ABC41A344374066AE1A2C3A7AEB818BTLVMBX01nicec_" --_000_07465C1D981ABC41A344374066AE1A2C3A7AEB818BTLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello I just published updated draft after WGLC comments. Main changes: 1. Ram's comments: aligning definitions and terms with requirements a= nd metadata drafts, figures fixing, references updates 2. Charles comments: a. Fixing B2BUA honoring statements (also was comment from Ram). Nex= t text: The B2BUA/SRC is responsible for complying with requests from recording awa= re UAs or through some configured policies indicating that the communicatio= n session should not be recorded. b. Terms fixing and spelling mistakes c. Rephrasing in section 3.1.4, 3.2, 32.2., 3.2.5. d. IANA reference to the protocol draft e. Updates in the security section 3. IETF 83 meeting minutes Leon --_000_07465C1D981ABC41A344374066AE1A2C3A7AEB818BTLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello=

 

I just p= ublished updated draft after WGLC comments.

 

Main changes:

<= p class=3DMsoNormal> 

1.&= nbsp;      Ram's comments: aligning definitions and terms with requirements an= d metadata drafts, figures fixing, references updates

= 2.       Charles comments:

a.     &n= bsp; Fixing  B2BUA hono= ring statements (also was comment from Ram). Next text:

The B2BUA/SRC is responsible for complying with requests f= rom recording aware UAs or through some configured policies indicating that= the communication session should not be recorded.

b.      <= /span>Terms fixing and spelling mis= takes

c.&nbs= p;      Rephrasing in section 3.1.4, 3.2, 32.2., 3.2.5.

d.      <= /span>IANA reference to the protoco= l draft

e.&n= bsp;     Updates in the security section

= 3.       IETF 83 meeting minutes

Le= on

 

= --_000_07465C1D981ABC41A344374066AE1A2C3A7AEB818BTLVMBX01nicec_-- --_004_07465C1D981ABC41A344374066AE1A2C3A7AEB818BTLVMBX01nicec_ Content-Type: text/plain; name="draft-ietf-siprec-architecture-05.txt" Content-Description: draft-ietf-siprec-architecture-05.txt Content-Disposition: attachment; filename="draft-ietf-siprec-architecture-05.txt"; size=33800; creation-date="Wed, 30 May 2012 12:36:23 GMT"; modification-date="Wed, 30 May 2012 12:36:24 GMT" Content-Transfer-Encoding: base64 CgoKU0lQUkVDICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEEuIEh1dHRvbiwgRWQuCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFNpZW1lbnMgRW50ZXJwcmlzZQpJbnRlbmRlZCBzdGF0dXM6ICBJbmZv cm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgICAgQ29tbXVuaWNhdGlvbnMKRXhwaXJl czogIERlY2VtYmVyIDEsIDIwMTIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTC4gUG9y dG1hbiwgRWQuCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIE5pY2UgU3lzdGVtcwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFIuIEphaW4KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElQQyBTeXN0ZW1z CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBLLiBSZWhvcgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIENpc2NvIFN5c3RlbXMsIEluYy4KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWF5IDMwLCAyMDEyCgoKICAgIEFu IEFyY2hpdGVjdHVyZSBmb3IgTWVkaWEgUmVjb3JkaW5nIHVzaW5nIHRoZSBTZXNzaW9uIEluaXRp YXRpb24KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQcm90b2NvbAogICAgICAgICAg ICAgICAgICAgZHJhZnQtaWV0Zi1zaXByZWMtYXJjaGl0ZWN0dXJlLTA1CgpBYnN0cmFjdAoKICAg U2Vzc2lvbiByZWNvcmRpbmcgaXMgYSBjcml0aWNhbCByZXF1aXJlbWVudCBpbiBtYW55IGNvbW11 bmljYXRpb25zCiAgIGVudmlyb25tZW50cyBzdWNoIGFzIGNhbGwgY2VudGVycyBhbmQgZmluYW5j aWFsIHRyYWRpbmcuICBJbiBzb21lIG9mCiAgIHRoZXNlIGVudmlyb25tZW50cywgYWxsIGNhbGxz IG11c3QgYmUgcmVjb3JkZWQgZm9yIHJlZ3VsYXRvcnksCiAgIGNvbXBsaWFuY2UsIGFuZCBjb25z dW1lciBwcm90ZWN0aW9uIHJlYXNvbnMuICBSZWNvcmRpbmcgb2YgYSBzZXNzaW9uCiAgIGlzIHR5 cGljYWxseSBwZXJmb3JtZWQgYnkgc2VuZGluZyBhIGNvcHkgb2YgYSBtZWRpYSBzdHJlYW0gdG8g YQogICByZWNvcmRpbmcgZGV2aWNlLiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYXJjaGl0ZWN0 dXJlcyBmb3IKICAgZGVwbG95aW5nIHNlc3Npb24gcmVjb3JkaW5nIHNvbHV0aW9ucyBpbiBhbiBl bnZpcm9ubWVudCB3aGljaCBpcwogICBiYXNlZCBvbiB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uIFBy b3RvY29sIChTSVApLgoKU3RhdHVzIG9mIHRoaXMgTWVtbwoKICAgVGhpcyBJbnRlcm5ldC1EcmFm dCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQogICBwcm92aXNpb25z IG9mIEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRv Y3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAoSUVURiku ICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUKICAgd29ya2luZyBk b2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5l dC0KICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3Vy cmVudC8uCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3Ig YSBtYXhpbXVtIG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwg b3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkKICAgdGltZS4gIEl0IGlzIGlu YXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UKICAgbWF0ZXJp YWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIgoKICAg VGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBEZWNlbWJlciAxLCAyMDEyLgoKQ29w eXJpZ2h0IE5vdGljZQoKICAgQ29weXJpZ2h0IChjKSAyMDEyIElFVEYgVHJ1c3QgYW5kIHRoZSBw ZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlCiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRz IHJlc2VydmVkLgoKCgpIdXR0b24sIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDEs IDIwMTIgICAgICAgICAgICAgICAgW1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgIEFyY2hp dGVjdHVyZSBmb3IgTWVkaWEgUmVjb3JkaW5nICAgICAgICAgICAgTWF5IDIwMTIKCgogICBUaGlz IGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2Fs CiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMKICAgKGh0dHA6Ly90cnVz dGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mCiAgIHB1 YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50 cwogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0 aW9ucyB3aXRoIHJlc3BlY3QKICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBl eHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QKICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJT RCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mCiAgIHRoZSBUcnVz dCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcwog ICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuCgoKVGFibGUgb2YgQ29u dGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgMwogICAyLiAgRGVmaW5pdGlvbnMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQKICAgMy4gIFNlc3Npb24gUmVj b3JkaW5nIEFyY2hpdGVjdHVyZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1CiAg ICAgMy4xLiAgTG9jYXRpb24gb2YgdGhlIFNlc3Npb24gUmVjb3JkaW5nIENsaWVudCAuIC4gLiAu IC4gLiAuIC4gLiAgNQogICAgICAgMy4xLjEuICBCMkJVQSBhY3RzIGFzIGEgU2Vzc2lvbiBSZWNv cmRpbmcgQ2xpZW50IC4gLiAuIC4gLiAuIC4gIDUKICAgICAgIDMuMS4yLiAgRW5kcG9pbnQgYWN0 cyBhcyBTZXNzaW9uIFJlY29yZGluZyBDbGllbnQgIC4gLiAuIC4gLiAuICA3CiAgICAgICAzLjEu My4gIEEgU0lQIFByb3h5IGNhbm5vdCBiZSBhIFNlc3Npb24gUmVjb3JkaW5nIENsaWVudCAuIC4g LiAgNwogICAgICAgMy4xLjQuICBJbnRlcmFjdGlvbiB3aXRoIE1FRElBQ1RSTCAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDgKICAgICAgIDMuMS41LiAgSW50ZXJhY3Rpb24gd2l0aCBDb25m ZXJlbmNlIEZvY3VzICAuIC4gLiAuIC4gLiAuIC4gLiAuICA5CiAgICAgMy4yLiAgRXN0YWJsaXNo aW5nIHRoZSBSZWNvcmRpbmcgU2Vzc2lvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMAogICAg ICAgMy4yLjEuICBTZXNzaW9uIFJlY29yZGluZyBDbGllbnQgSW5pdGlhdGVkIFJlY29yZGluZyAu IC4gLiAuIC4gMTEKICAgICAgIDMuMi4yLiAgU2Vzc2lvbiBSZWNvcmRpbmcgU2VydmVyIEluaXRp YXRlZCBSZWNvcmRpbmcgLiAuIC4gLiAuIDExCiAgICAgICAzLjIuMy4gIFBhdXNlL1Jlc3VtZSBS ZWNvcmRpbmcgU2Vzc2lvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMgogICAgICAgMy4yLjQu ICBNZWRpYSBTdHJlYW0gTWl4aW5nICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTIKICAgICAgIDMuMi41LiAgTWVkaWEgVHJhbnNjb2RpbmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDEyCiAgICAgMy4zLiAgUmVjb3JkaW5nIE1ldGFkYXRhIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMgogICAgICAgMy4zLjEuICBDb250ZW50 cyBvZiByZWNvcmRpbmcgbWV0YWRhdGEgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMKICAgICAg IDMuMy4yLiAgTWVjaGFuaXNtcyBmb3IgZGVsaXZlcnkgb2YgbWV0YWRhdGEgdG8gU2Vzc2lvbgog ICAgICAgICAgICAgICBSZWNvcmRpbmcgU2VydmVyIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTMKICAgICAzLjQuICBOb3RpZmljYXRpb25zIHRvIHRoZSBSZWNvcmRlZCBV c2VyIEFnZW50cyAgLiAuIC4gLiAuIC4gLiAuIDEzCiAgICAgMy41LiAgUHJldmVudGluZyB0aGUg cmVjb3JkaW5nIG9mIGEgU0lQIHNlc3Npb24gIC4gLiAuIC4gLiAuIC4gLiAxMwogICA0LiAgSUFO QSBjb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMTMKICAgNS4gIFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDE0CiAgIDYuICBBY2tub3dsZWRnZW1lbnRzIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNAogICA3LiAgSW5mb3JtYXRpdmUg UmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTQKICAg QXV0aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDE1CgoKCgoKCgoKCgoKCkh1dHRvbiwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMg RGVjZW1iZXIgMSwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0 ICAgICAgQXJjaGl0ZWN0dXJlIGZvciBNZWRpYSBSZWNvcmRpbmcgICAgICAgICAgICBNYXkgMjAx MgoKCjEuICBJbnRyb2R1Y3Rpb24KCiAgIFNlc3Npb24gcmVjb3JkaW5nIGlzIGEgY3JpdGljYWwg cmVxdWlyZW1lbnQgaW4gbWFueSBjb21tdW5pY2F0aW9ucwogICBlbnZpcm9ubWVudHMgc3VjaCBh cyBjYWxsIGNlbnRlcnMgYW5kIGZpbmFuY2lhbCB0cmFkaW5nLiAgSW4gc29tZSBvZgogICB0aGVz ZSBlbnZpcm9ubWVudHMsIGFsbCBjYWxscyBtdXN0IGJlIHJlY29yZGVkIGZvciByZWd1bGF0b3J5 LAogICBjb21wbGlhbmNlLCBhbmQgY29uc3VtZXIgcHJvdGVjdGlvbiByZWFzb25zLiAgUmVjb3Jk aW5nIG9mIGEgc2Vzc2lvbgogICBpcyB0eXBpY2FsbHkgcGVyZm9ybWVkIGJ5IHNlbmRpbmcgYSBj b3B5IG9mIGEgbWVkaWEgc3RyZWFtIHRvIGEKICAgcmVjb3JkaW5nIGRldmljZS4gIFRoaXMgZG9j dW1lbnQgZGVzY3JpYmVzIGFyY2hpdGVjdHVyZXMgZm9yCiAgIGRlcGxveWluZyBzZXNzaW9uIHJl Y29yZGluZyBzb2x1dGlvbnMgaW4gYW4gZW52aXJvbm1lbnQgd2hpY2ggaXMKICAgYmFzZWQgb24g dGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSB0aGUgcmVxdWlyZW1lbnRzIGZv cgogICB3aGljaCBhcmUgZGVzY3JpYmVkIGluIFtSRkM2MzQxXS4KCiAgIFRoaXMgZG9jdW1lbnQg Zm9jdXNlcyBvbiBob3cgc2Vzc2lvbnMgYXJlIGVzdGFibGlzaGVkIGJldHdlZW4gYQogICBTZXNz aW9uIFJlY29yZGluZyBDbGllbnQgKFNSQykgYW5kIHRoZSBTZXNzaW9uIFJlY29yZGluZyBTZXJ2 ZXIgKFNSUykKICAgZm9yIHRoZSBwdXJwb3NlIG9mIGNvbnZleWluZyB0aGUgUmVwbGljYXRlZCBN ZWRpYSBhbmQgUmVjb3JkaW5nCiAgIE1ldGFkYXRhIChlLmcuICBJZGVudGl0eSBvZiBwYXJ0aWVz IGludm9sdmVkKSByZWxhdGluZyB0byB0aGUKICAgQ29tbXVuaWNhdGlvbiBTZXNzaW9uLgoKICAg T25jZSB0aGUgUmVwbGljYXRlZCBNZWRpYSBhbmQgUmVjb3JkaW5nIE1ldGFkYXRhIGhhdmUgYmVl biByZWNlaXZlZAogICBieSB0aGUgU2Vzc2lvbiBSZWNvcmRpbmcgU2VydmVyIHRoZXkgd2lsbCB0 eXBpY2FsbHkgYmUgYXJjaGl2ZWQgZm9yCiAgIHJldHJpZXZhbCBhdCBhIGxhdGVyIHRpbWUuICBU aGUgcHJvY2VkdXJlcyByZWxhdGluZyB0byB0aGUgYXJjaGl2aW5nCiAgIGFuZCByZXRyaWV2YWwg b2YgdGhpcyBpbmZvcm1hdGlvbiBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzCiAgIGRvY3Vt ZW50LgoKICAgVGhpcyBkb2N1bWVudCBvbmx5IGNvbnNpZGVycyBhY3RpdmUgcmVjb3JkaW5nLCB3 aGVyZSB0aGUgU2Vzc2lvbgogICBSZWNvcmRpbmcgQ2xpZW50IHB1cnBvc2VmdWxseSBzdHJlYW1z IG1lZGlhIHRvIGEgU2Vzc2lvbiBSZWNvcmRpbmcKICAgU2VydmVyLiAgUGFzc2l2ZSByZWNvcmRp bmcsIHdoZXJlIGEgcmVjb3JkaW5nIGRldmljZSBkZXRlY3RzIG1lZGlhCiAgIGRpcmVjdGx5IGZy b20gdGhlIG5ldHdvcmsgKEUuZy4gdXNpbmcgcG9ydCBtaXJyb3JpbmcgdGVjaG5pcXVlcyksIGlz CiAgIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuICBJbiBhZGRpdGlvbiwgbGF3 ZnVsIGludGVyY2VwdCBpcwogICBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50IHdo aWNoIHRha2VzIGFjY291bnQgb2YgdGhlIElFVEYKICAgcG9saWN5IG9uIHdpcmV0YXBwaW5nIFtS RkMyODA0XS4KCiAgIFRoZSBSZWNvcmRpbmcgU2Vzc2lvbiB0aGF0IGlzIGVzdGFibGlzaGVkIGJl dHdlZW4gdGhlIFNlc3Npb24KICAgUmVjb3JkaW5nIENsaWVudCBhbmQgdGhlIFNlc3Npb24gUmVj b3JkaW5nIFNlcnZlciB1c2VzIHRoZSBub3JtYWwKICAgcHJvY2VkdXJlcyBmb3IgZXN0YWJsaXNo aW5nIElOVklURSBpbml0aWF0ZWQgZGlhbG9ncyBhcyBzcGVjaWZpZWQgaW4KICAgW1JGQzMyNjFd IGFuZCB1c2VzIFNEUCBmb3IgZGVzY3JpYmluZyB0aGUgbWVkaWEgdG8gYmUgdXNlZCBkdXJpbmcg dGhlCiAgIHNlc3Npb24gYXMgc3BlY2lmaWVkIGluIFtSRkM0NTY2XS4gIEhvd2V2ZXIgaXQgaXMg aW50ZW5kZWQgdGhhdCBzb21lCiAgIGV4dGVuc2lvbnMgdG8gU0lQIChFLmcuICBIZWFkZXJzLCBP cHRpb24gVGFncywgRXRjLikgd2lsbCBiZSBkZWZpbmVkCiAgIHRvIHN1cHBvcnQgdGhlIHJlcXVp cmVtZW50cyBmb3IgbWVkaWEgcmVjb3JkaW5nLiAgVGhlIFJlcGxpY2F0ZWQKICAgTWVkaWEgaXMg cmVxdWlyZWQgdG8gYmUgc2VudCBpbiByZWFsLXRpbWUgdG8gdGhlIFNlc3Npb24gUmVjb3JkaW5n CiAgIFNlcnZlciBhbmQgaXMgbm90IGJ1ZmZlcmVkIGJ5IHRoZSBTZXNzaW9uIFJlY29yZGluZyBD bGllbnQgdG8gYWxsb3cKICAgZm9yIHJlYWwtdGltZSBhbmFseXNpcyBvZiB0aGUgbWVkaWEgYnkg dGhlIFNlc3Npb24gUmVjb3JkaW5nIFNlcnZlci4KCgoKCgoKCgoKSHV0dG9uLCBldCBhbC4gICAg ICAgICAgRXhwaXJlcyBEZWNlbWJlciAxLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDNdCgwK SW50ZXJuZXQtRHJhZnQgICAgICBBcmNoaXRlY3R1cmUgZm9yIE1lZGlhIFJlY29yZGluZyAgICAg ICAgICAgIE1heSAyMDEyCgoKMi4gIERlZmluaXRpb25zCgogICBTZXNzaW9uIFJlY29yZGluZyBT ZXJ2ZXIgKFNSUyk6ICBBIFNlc3Npb24gUmVjb3JkaW5nIFNlcnZlciAoU1JTKSBpcwogICBhIFNJ UCBVc2VyIEFnZW50IChVQSkgdGhhdCBpcyBhIHNwZWNpYWxpemVkIG1lZGlhIHNlcnZlciBvciBj b2xsZWN0b3IKICAgdGhhdCBhY3RzIGFzIHRoZSBzaW5rIG9mIHRoZSByZWNvcmRlZCBtZWRpYS4g IEFuIFNSUyBpcyB0eXBpY2FsbHkKICAgaW1wbGVtZW50ZWQgYXMgYSBtdWx0aS1wb3J0IGRldmlj ZSB0aGF0IGlzIGNhcGFibGUgb2YgcmVjZWl2aW5nIG1lZGlhCiAgIGZyb20gbXVsdGlwbGUgc291 cmNlcyBzaW11bHRhbmVvdXNseS4gIEFuIFNSUyBpcyB0aGUgc2luayBvZiB0aGUKICAgcmVjb3Jk ZWQgc2Vzc2lvbiBtZXRhZGF0YS4KCiAgIFNlc3Npb24gUmVjb3JkaW5nIENsaWVudCAoU1JDKTog IEEgU2Vzc2lvbiBSZWNvcmRpbmcgQ2xpZW50IChTUkMpIGlzCiAgIGEgU0lQIFVzZXIgQWdlbnQg KFVBKSB0aGF0IGFjdHMgYXMgdGhlIHNvdXJjZSBvZiB0aGUgcmVjb3JkZWQgbWVkaWEsCiAgIHNl bmRpbmcgaXQgdG8gdGhlIFNSUy4gIEFuIFNSQyBpcyBhIGxvZ2ljYWwgZnVuY3Rpb24uICBJdHMK ICAgY2FwYWJpbGl0aWVzIG1heSBiZSBpbXBsZW1lbnRlZCBhY3Jvc3Mgb25lIG9yIG1vcmUgcGh5 c2ljYWwgZGV2aWNlcy4KICAgSW4gcHJhY3RpY2UsIGFuIFNSQyBjb3VsZCBiZSBhIHBlcnNvbmFs IGRldmljZSAoc3VjaCBhcyBhIFNJUCBwaG9uZSksCiAgIGEgU0lQIE1lZGlhIEdhdGV3YXkgKE1H KSwgYSBTZXNzaW9uIEJvcmRlciBDb250cm9sbGVyIChTQkMpIG9yIGEgU0lQCiAgIE1lZGlhIFNl cnZlciAoTVMpIGludGVncmF0ZWQgd2l0aCBhbiBBcHBsaWNhdGlvbiBTZXJ2ZXIgKEFTKS4gIFRo aXMKICAgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIHRoZSB0ZXJtIFNSQyBzdWNoIHRoYXQgYWxsIHN1 Y2ggU0lQIGVudGl0aWVzCiAgIGNhbiBiZSBnZW5lcmljYWxseSBhZGRyZXNzZWQgdW5kZXIgb25l IGRlZmluaXRpb24uICBUaGUgU1JDIHByb3ZpZGVzCiAgIG1ldGFkYXRhIHRvIHRoZSBTUlMuCgog ICBDb21tdW5pY2F0aW9uIFNlc3Npb24gKENTKTogIEEgc2Vzc2lvbiBjcmVhdGVkIGJldHdlZW4g dHdvIG9yIG1vcmUKICAgU0lQIFVzZXIgQWdlbnRzIChVQXMpIHRoYXQgaXMgdGhlIHN1YmplY3Qg b2YgcmVjb3JkaW5nLgoKICAgUmVjb3JkaW5nIFNlc3Npb24gKFJTKTogIFRoZSBTSVAgc2Vzc2lv biBjcmVhdGVkIGJldHdlZW4gYW4gU1JDIGFuZAogICBTUlMgZm9yIHRoZSBwdXJwb3NlIG9mIHJl Y29yZGluZyBhIENvbW11bmljYXRpb24gU2Vzc2lvbi4KCiAgIFJlY29yZGluZyBhd2FyZSBVc2Vy IEFnZW50IChVQSk6ICBBIFNJUCBVc2VyIEFnZW50IHRoYXQgaXMgYXdhcmUgb2YKICAgU0lQIGV4 dGVuc2lvbnMgYXNzb2NpYXRlZCB3aXRoIHRoZSBDb21tdW5pY2F0aW9uIFNlc3Npb24uICBTdWNo CiAgIGV4dGVuc2lvbnMgbWF5IGJlIHVzZWQgdG8gbm90aWZ5IHRoZSBSZWNvcmRpbmcgYXdhcmUg VUEgdGhhdCBhCiAgIHNlc3Npb24gaXMgYmVpbmcgcmVjb3JkZWQsIG9yIGJ5IGEgUmVjb3JkaW5n IGF3YXJlIFVBIHRvIGV4cHJlc3MKICAgcHJlZmVyZW5jZXMgYXMgdG8gd2hldGhlciBhIHJlY29y ZGluZyBzaG91bGQgYmUgc3RhcnRlZCwgcGF1c2VkLAogICByZXN1bWVkIG9yIHN0b3BwZWQuCgog ICBSZWNvcmRpbmcgdW5hd2FyZSBVc2VyIEFnZW50IChVQSk6ICBBIFNJUCBVc2VyIEFnZW50IHRo YXQgaXMgdW5hd2FyZQogICBvZiBTSVAgZXh0ZW5zaW9ucyBhc3NvY2lhdGVkIHdpdGggdGhlIENv bW11bmljYXRpb24gU2Vzc2lvbi4gIFN1Y2gKICAgUmVjb3JkaW5nIHVuYXdhcmUgVUEgd2lsbCBi ZSBub3RpZmllZCB0aGF0IGEgc2Vzc2lvbiBpcyBiZWluZwogICByZWNvcmRlZCBvciBleHByZXNz IHByZWZlcmVuY2VzIGFzIHRvIHdoZXRoZXIgYSByZWNvcmRpbmcgc2hvdWxkIGJlCiAgIHN0YXJ0 ZWQsIHBhdXNlZCwgcmVzdW1lZCBvciBzdG9wcGVkIHZpYSBzb21lIG90aGVyIG1lYW5zIHRoYXQg aXMgb3V0CiAgIG9mIHNjb3BlIG9mIFNJUFJFQy4KCiAgIFJlY29yZGluZyBNZXRhZGF0YTogIFRo ZSBtZXRhZGF0YSBkZXNjcmliaW5nIHRoZSBjb21tdW5pY2F0aW9uCiAgIHNlc3Npb24gdGhhdCBp cyByZXF1aXJlZCBieSB0aGUgU2Vzc2lvbiBSZWNvcmRpbmcgU2VydmVyLiAgVGhpcyB3aWxsCiAg IGluY2x1ZGUgZm9yIGV4YW1wbGUgdGhlIGlkZW50aXR5IG9mIHVzZXJzIHRoYXQgcGFydGljaXBh dGUgaW4gdGhlCiAgIENvbW11bmljYXRpb24gU2Vzc2lvbiBhbmQgZGlhbG9nIHN0YXRlLiAgVHlw aWNhbGx5IHRoaXMgbWV0YWRhdGEgaXMKICAgYXJjaGl2ZWQgd2l0aCB0aGUgcmVwbGljYXRlZCBt ZWRpYSBhdCB0aGUgU2Vzc2lvbiBSZWNvcmRpbmcgU2VydmVyLgogICBUaGUgcmVjb3JkaW5nIG1l dGFkYXRhIGlzIGRlbGl2ZXJlZCBpbiByZWFsLXRpbWUgdG8gdGhlIFNlc3Npb24KICAgUmVjb3Jk aW5nIFNlcnZlci4KCgoKCkh1dHRvbiwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIg MSwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0LURyYWZ0ICAgICAgQXJj aGl0ZWN0dXJlIGZvciBNZWRpYSBSZWNvcmRpbmcgICAgICAgICAgICBNYXkgMjAxMgoKCiAgIFJl cGxpY2F0ZWQgTWVkaWE6ICBBIGNvcHkgb2YgdGhlIG1lZGlhIGFzc29jaWF0ZWQgd2l0aCB0aGUK ICAgQ29tbXVuaWNhdGlvbiBTZXNzaW9uIGNyZWF0ZWQgYnkgdGhlIFNlc3Npb24gUmVjb3JkaW5n IENsaWVudCBhbmQKICAgc2VudCB0byB0aGUgU2Vzc2lvbiBSZWNvcmRpbmcgU2VydmVyLiAgSXQg bWF5IGNvbnRhaW4gYWxsIHRoZSBtZWRpYQogICBhc3NvY2lhdGVkIHdpdGggdGhlIGNvbW11bmlj YXRpb24gc2Vzc2lvbiAoRS5nLiAgQXVkaW8gYW5kIFZpZGVvKSBvcgogICBqdXN0IGEgc3Vic2V0 IChFLmcuICBBdWRpbykuICBSZXBsaWNhdGVkIE1lZGlhIGlzIHBhcnQgb2YgUmVjb3JkaW5nCiAg IFNlc3Npb24uCgoKMy4gIFNlc3Npb24gUmVjb3JkaW5nIEFyY2hpdGVjdHVyZQoKMy4xLiAgTG9j YXRpb24gb2YgdGhlIFNlc3Npb24gUmVjb3JkaW5nIENsaWVudAoKICAgVGhpcyBzZWN0aW9uIGNv bnRhaW5zIHNvbWUgZXhhbXBsZSBzZXNzaW9uIHJlY29yZGluZyBhcmNoaXRlY3R1cmVzCiAgIHNo b3dpbmcgaG93IHRoZSBTZXNzaW9uIFJlY29yZGluZyBDbGllbnQgaXMgYSBsb2dpY2FsIGZ1bmN0 aW9uIHRoYXQKICAgY2FuIGJlIGxvY2F0ZWQgaW4gb3Igc3BsaXQgYmV0d2VlbiB2YXJpb3VzIHBo eXNpY2FsIGNvbXBvbmVudHMuCgozLjEuMS4gIEIyQlVBIGFjdHMgYXMgYSBTZXNzaW9uIFJlY29y ZGluZyBDbGllbnQKCiAgIEEgU0lQIEJhY2sgdG8gQmFjayBVc2VyIEFnZW50IChCMkJVQSkgd2hp Y2ggaGFzIGFjY2VzcyB0byB0aGUgbWVkaWEKICAgdGhhdCBpcyB0byBiZSByZWNvcmRlZCBtYXkg YWN0IGFzIGEgU2Vzc2lvbiBSZWNvcmRpbmcgQ2xpZW50LiAgVGhlCiAgIEIyQlVBIG1heSBhbHJl YWR5IGJlIGF3YXJlIHRoYXQgYSBzZXNzaW9uIG5lZWRzIHRvIGJlIHJlY29yZGVkIGJlZm9yZQog ICB0aGUgaW5pdGlhbCBlc3RhYmxpc2htZW50IG9mIHRoZSBjb21tdW5pY2F0aW9uIHNlc3Npb24g b3IgdGhlCiAgIGRlY2lzaW9uIHRvIHJlY29yZCB0aGUgc2Vzc2lvbiBtYXkgb2NjdXIgYWZ0ZXIg dGhlIHNlc3Npb24gaGFzIGJlZW4KICAgZXN0YWJsaXNoZWQuCgogICBJZiB0aGUgQjJCVUEvU1JD IG1ha2VzIHRoZSBkZWNpc2lvbiB0byBpbml0aWF0ZSB0aGUgUmVjb3JkaW5nIFNlc3Npb24KICAg KFJTKSB0aGVuIGl0IHdpbGwgaW5pdGlhdGUgdGhlIGVzdGFibGlzaG1lbnQgb2YgYSBTSVAgU2Vz c2lvbiBieQogICBzZW5kaW5nIGFuIElOVklURSB0byB0aGUgU2Vzc2lvbiBSZWNvcmRpbmcgU2Vy dmVyLgoKICAgSWYgdGhlIFNlc3Npb24gUmVjb3JkaW5nIFNlcnZlciBtYWtlcyB0aGUgZGVjaXNp b24gdG8gaW5pdGlhdGUgdGhlCiAgIHJlY29yZGluZyBzZXNzaW9uIHRoZW4gaXQgd2lsbCBpbml0 aWF0ZSB0aGUgZXN0YWJsaXNobWVudCBvZiBhIFNJUAogICBTZXNzaW9uIGJ5IHNlbmRpbmcgYW4g SU5WSVRFIHRvIHRoZSBCMkJVQS9TZXNzaW9uIFJlY29yZGluZyBDbGllbnQuCgogICBUaGUgUlMg SU5WSVRFIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlkZW50aWZpZXMgdGhlIHNlc3Npb24g YXMKICAgYmVpbmcgZXN0YWJsaXNoZWQgZm9yIHRoZSBwdXJwb3NlcyBvZiByZWNvcmRpbmcgYW5k IHByZXZlbnRzIHRoZQogICBzZXNzaW9uIGZyb20gYmVpbmcgYWNjaWRlbnRseSByZXJvdXRlZCB0 byBhIFVBIHdoaWNoIGlzIG5vdCBhIFNSUy4KCiAgIFRoZSBCMkJVQS9TUkMgaXMgcmVzcG9uc2li bGUgZm9yIG5vdGlmeWluZyB0aGUgVUFzIGludm9sdmVkIGluIHRoZQogICBjb21tdW5pY2F0aW9u IHNlc3Npb24gdGhhdCB0aGUgc2Vzc2lvbiBpcyBiZWluZyByZWNvcmRlZC4KCiAgIFRoZSBCMkJV QS9TUkMgaXMgcmVzcG9uc2libGUgZm9yIGNvbXBseWluZyB3aXRoIHJlcXVlc3RzIGZyb20KICAg cmVjb3JkaW5nIGF3YXJlIFVBcyBvciB0aHJvdWdoIHNvbWUgY29uZmlndXJlZCBwb2xpY2llcyBp bmRpY2F0aW5nCiAgIHRoYXQgdGhlIGNvbW11bmljYXRpb24gc2Vzc2lvbiBzaG91bGQgbm90IGJl IHJlY29yZGVkLgoKCgoKCgoKCkh1dHRvbiwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1i ZXIgMSwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0LURyYWZ0ICAgICAg QXJjaGl0ZWN0dXJlIGZvciBNZWRpYSBSZWNvcmRpbmcgICAgICAgICAgICBNYXkgMjAxMgoKCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0r CiAgICAgICAgICAgICAgICAgICAgICAgICAgKFJlY29yZGluZyBTZXNzaW9uKSB8ICBTZXNzaW9u ICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLVNJUC0tLS0tLT58IFJlY29y ZGluZyB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8ICBT ZXJ2ZXIgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgKy0tUlRQL1JUQ1AtLT58 ICAoU1JTKSAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgfCAgICAgICAgICAg ICArLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgViAgViAgICAgICAg ICAgICAgICAgICBeCiAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tKyAgICAg ICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAg ICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfC0tIE1ldGFEYXRh IC0rCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfAogICAgICAgICAgICAg ICAgICAgICAgICB8ICAgIEIyQlVBICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgIHwgICBTZXNzaW9uICAgfAogICAgICst LS0tLS0tLSsgICAgICAgICB8ICBSZWNvcmRpbmcgIHwgICAgICAgICArLS0tLS0tLS0tKwogICAg IHwgICAgICAgIHw8LSBTSVAgLT58ICAgQ2xpZW50ICAgIHw8LSBTSVAgLT58ICAgICAgICAgfAog ICAgIHwgIFVBLUEgIHwgICAgICAgICB8ICAgKFNSQykgICAgIHwgICAgICAgICB8ICBVQS1CICAg fAogICAgIHwgICAgICAgIHw8LSBSVFAvLT58ICAgICAgICAgICAgIHw8LSBSVFAvLT58ICAgICAg ICAgfAogICAgICstLS0tLS0tLSsgICBSVENQICB8ICAgICAgICAgICAgIHwgICBSVENQICArLS0t LS0tLS0tKwogICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLSsKICAgICB8X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX3wKICAgICAg ICAgICAgICAgICAgICAoQ29tbXVuaWNhdGlvbiBTZXNzaW9uKQoKICAgICAgICAgIEZpZ3VyZSAx OiBCMkJVQSBBY3RzIGFzIHRoZSBTZXNzaW9uIFJlY29yZGluZyBDbGllbnQuCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCkh1dHRvbiwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIg MSwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSA2XQoMCkludGVybmV0LURyYWZ0ICAgICAgQXJj aGl0ZWN0dXJlIGZvciBNZWRpYSBSZWNvcmRpbmcgICAgICAgICAgICBNYXkgMjAxMgoKCjMuMS4y LiAgRW5kcG9pbnQgYWN0cyBhcyBTZXNzaW9uIFJlY29yZGluZyBDbGllbnQKCiAgIEEgU0lQIEVu ZHBvaW50IC8gVUEgbWF5IGFjdCBhcyBhIFNlc3Npb24gUmVjb3JkaW5nIENsaWVudCBpbiB3aGlj aAogICBjYXNlIHRoZSBlbmRwb2ludCBzZW5kcyB0aGUgUmVwbGljYXRlZCBNZWRpYSB0byB0aGUg U2Vzc2lvbiBSZWNvcmRpbmcKICAgU2VydmVyCgogICBJZiB0aGUgZW5kcG9pbnQgbWFrZXMgdGhl IGRlY2lzaW9uIHRvIGluaXRpYXRlIHRoZSBSZWNvcmRpbmcgU2Vzc2lvbgogICB0aGVuIGl0IHdp bGwgaW5pdGlhdGUgdGhlIGVzdGFibGlzaG1lbnQgb2YgYSBTSVAgU2Vzc2lvbiBieSBzZW5kaW5n CiAgIGFuIElOVklURSB0byB0aGUgU2Vzc2lvbiBSZWNvcmRpbmcgU2VydmVyLgoKICAgSWYgdGhl IFNlc3Npb24gUmVjb3JkaW5nIFNlcnZlciBtYWtlcyB0aGUgZGVjaXNpb24gdG8gaW5pdGlhdGUg dGhlCiAgIFJlY29yZGluZyBTZXNzaW9uIHRoZW4gaXQgd2lsbCBpbml0aWF0ZSB0aGUgZXN0YWJs aXNobWVudCBvZiBhIFNJUAogICBTZXNzaW9uIGJ5IHNlbmRpbmcgYW4gSU5WSVRFIHRvIHRoZSBl bmRwb2ludC4gIFRoZSBhY3R1YWwgZGVjaXNpb24KICAgbWVjaGFuaXNtIGlzIG91dCBvZiBzY29w ZSBvZiBTSVBSRUMuCgoKCiAgICAgICAgICAoUmVjb3JkaW5nIFNlc3Npb24pICstLS0tLS0tLS0t LSsKICAgICAgICAgKy0tLS0tLS0tLS1TSVAtLS0tLS0+fCAgICAgICAgICAgfAogICAgICAgICB8 ICArLS0tLVJUUC9SVENQLS0tLT58ICBTZXNzaW9uICB8CiAgICAgICAgIHwgIHwgICAgICAgICAg ICAgICAgIHwgUmVjb3JkaW5nIHwKICAgICAgICAgfCAgfCAgICAgICAgICAgICAgICAgfCAgU2Vy dmVyICAgfAogICAgICAgICB8ICB8ICstLSBNZXRhZGF0YSAtLT58ICAgKFNSUykgICB8CiAgICAg ICAgIHwgIHwgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwKICAgICAgICAgfCAgfCB8ICAg ICAgICAgICAgICAgKy0tLS0tLS0tLS0tKwogICAgICAgICB8ICB8IHwKICAgICAgICAgfCAgfCB8 CiAgICAgICAgIHwgIHwgfAogICAgICAgICB8ICB8IHwKICAgICAgICAgViAgViB8ICAoQ29tbXVu aWNhdGlvbiBTZXNzaW9uKQogICAgICArLS0rLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICst LS0tLS0tLS0rCiAgICAgIHwgICAgICAgICB8PC0tLS0tLS1TSVAtLS0tLS0tLS0+fCAgICAgICAg IHwKICAgICAgfCAgVUEtQSAgIHwgICAgICAgICAgICAgICAgICAgICB8ICBVQS1CICAgfAogICAg ICB8ICAoU1JDKSAgfDwtLS0tLVJUUC9SVENQLS0tLS0tPnwgICAgICAgICB8CiAgICAgICstLS0t LS0tLS0rICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLSsKCgogICAgICBGaWd1cmUgMjog U0lQIEVuZHBvaW50IGFjdHMgYXMgdGhlIFNlc3Npb24gUmVjb3JkaW5nIENsaWVudAoKCgozLjEu My4gIEEgU0lQIFByb3h5IGNhbm5vdCBiZSBhIFNlc3Npb24gUmVjb3JkaW5nIENsaWVudAoKICAg QSBTSVAgUHJveHkgaXMgdW5hYmxlIHRvIGFjdCBhcyBhbiBTUkMgYmVjYXVzZSBpdCBkb2VzIG5v dCBoYXZlCiAgIGFjY2VzcyB0byB0aGUgbWVkaWEgYW5kIHRoZXJlZm9yZSBoYXMgbm8gd2F5IG9m IGVuYWJsaW5nIHRoZSBkZWxpdmVyeQogICBvZiB0aGUgcmVwbGljYXRlZCBtZWRpYSB0byB0aGUg U1JTCgoKCgoKSHV0dG9uLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAxLCAyMDEy ICAgICAgICAgICAgICAgIFtQYWdlIDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICBBcmNoaXRlY3R1 cmUgZm9yIE1lZGlhIFJlY29yZGluZyAgICAgICAgICAgIE1heSAyMDEyCgoKMy4xLjQuICBJbnRl cmFjdGlvbiB3aXRoIE1FRElBQ1RSTAoKICAgVGhlIG1lZGlhY3RybCBhcmNoaXRlY3R1cmUgW1JG QzU1NjddIGRlc2NyaWJlcyBhbiBhcmNoaXRlY3VyZSBpbgogICB3aGljaCBhbiBBcHBsaWNhdGlv biBTZXJ2ZXIgKEFTKSBjb250cm9scyBhIE1lZGlhIFNlcnZlciAoTVMpIHdoaWNoCiAgIG1heSBi ZSB1c2VkIGZvciBwdXJwb3NlcyBzdWNoIGFzIGNvbmZlcmVuY2luZyBhbmQgcmVjb3JkaW5nIG1l ZGlhCiAgIHN0cmVhbXMuICBJbiB0aGUgW1JGQzU1NjddIGFyY2hpdGVjdXJlIHRoZSBBUyB0eXBp Y2FsbHkgdXNlcyBTSVAKICAgVGhpcmQgUGFydHkgQ2FsbCBDb250cm9sICgzUENDKSB0byBpbnN0 cnVjdCB0aGUgU0lQIFVBcyB0byBkaXJlY3QKICAgdGhlaXIgbWVkaWEgdG8gdGhlIE1lZGlhIFNl cnZlci4KCiAgIFRoZSBTZXNzaW9uIFJlY29yZGluZyBDbGllbnQgYW5kIFNlc3Npb24gUmVjb3Jk aW5nIFNlcnZlciBkZXNjcmliZWQKICAgaW4gdGhpcyBkb2N1bWVudCBtYXkgYWN0IGFzIGFuIGFw cGxpY2F0aW9uIHNlcnZlciBhcyBkZXNjcmliZWQgaW4KICAgW1JGQzU1NjddOyBhbmQgdGhlcmVm b3JlLCB3aGVuIGZ1cnRoZXIgZGVjb21wb3NlZCwgbWF5IGJlIG1hZGUgdXAgb2YKICAgYW4gYXBw bGljYXRpb24gc2VydmVyIHdoaWNoIHVzZXMgYSBtZWRpYWN0cmwgaW50ZXJmYWNlIHRvIGNvbnRy b2wgYQogICBtZWRpYSBzZXJ2ZXIgZm9yIHRoZSBwdXJwb3NlIG9mIHJlY29yZGluZyB0aGUgbWVk aWEgc3RyZWFtcy4KICAgSG93ZXZlciwgdGhpcyBpbnRlcmZhY2UgaXMgY29uc2lkZXJlZCBvdXRz aWRlIHRoZSBzY29wZSBvZiB0aGlzCiAgIGRvY3VtZW50LgoKCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBTZXNzaW9uIFJlY29yZGluZyBTZXJ2ZXIgKFNSUykKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgKFJlY29yZGluZyBTZXNzaW9uKSB8ICAr LS0tLS0tLS0tLS0rICAgICAgICAgICstLS0tLS0tLS0tLS0rIHwKICAgICAgICAgICstLS0tLS0t LS0tLS1TSVAtLS0tfC0+fCAgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICAgfCB8CiAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgIHwgIHwgTWVkaWFDdHJsIHxNRURJQUNUUkwgfCAg IE1lZGlhICAgIHwgfAogICAgICAgICAgfCAgICAgICAgICAgICAgICAgICB8ICB8QXBwbGljYXRp b258PC0tLS0tLS0tPnwgICBTZXJ2ZXIgICB8IHwKICAgICAgICAgIHwgICAgKy0tLS0tTWV0YWRh dGEtLS0+fCAgU2VydmVyICAgfCAgICAgICAgICB8ICAoUmVjb3JkZXIpfCB8CiAgICAgICAgICB8 ICAgIHwgICAgICAgICAgICAgIHwgIHwgICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICAg IHwgfAogICAgICAgICAgfCAgICB8ICAgICAgICAgICAgICB8ICArLS0tLS0tLS0tLS0rICAgICAg ICAgICstLS0tLS0tLS0tLS0rIHwKICAgICAgICAgIHwgICAgfCAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIF4gICAgICAgICB8CiAgICAgICAgICB8ICAgIHwgICAg ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18LS0tLS0tLS0tKwogICAg ICAgICAgfCAgICB8ICArLS0tLS0tLS0tLS0tLS0tIFJUUC9SVENQIC0tLS0tLS0tLS0tLS0tLS0t KwogICAgICAgICAgfCAgICB8ICB8CiAgICAgICAgICBWICAgIHwgIFYKICAgICAgICArLS0tKy0t LS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0rCiAgICAgICAgfCAgICAg ICAgICB8PC0tLS0tLS1TSVAtLS0tLS0tLS0tLS0tLT58ICAgICAgICAgfAogICAgICAgIHwgICBV QS1BICAgfCAoQ29tbXVuaWNhdGlvbiBTZXNzaW9uKSAgfCAgVUEtQiAgIHwKICAgICAgICB8ICAg KFNSQykgIHw8LS0tLS0tLVJUUC9SVENQLS0tLS0tLS0tPnwgICAgICAgICB8CiAgICAgICAgKy0t LS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tKwoKICAgICAgICAg ICBGaWd1cmUgMzogRXhhbXBsZSBvZiBTZXNzaW9uIFJlY29yZGluZyBTZXJ2ZXIgdXNpbmcgTUVE SUFDVFJMCgoKCgoKCgoKCgoKSHV0dG9uLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJl ciAxLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDhdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBB cmNoaXRlY3R1cmUgZm9yIE1lZGlhIFJlY29yZGluZyAgICAgICAgICAgIE1heSAyMDEyCgoKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0t LS0tKwogICAgICAgICAgICAgICAgIChSZWNvcmRpbmcgU2Vzc2lvbikgICAgICAgICAgICAgICAg fCBTZXNzaW9uICB8CiAgICAgICAgICAgKy0tLS0tLS0tLS0tU0lQLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLT58UmVjb3JkaW5nIHwKICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgIFNlcnZlciAgfAogICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgIChTUlMpICB8CiAgICAgICAgICAgfCAgVUEtQSBT ZXNzaW9uIFJlY29yZGluZyBDbGllbnQgKFNSQykgICArLS0tLS0tLS0tLSsKICAgICstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgIF4KICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgIHwKICAgIHwgICstLS0t LS0tLS0tLSsgICAgICAgICAgKy0tLS0tLS0tLS0tLSsgfCAgICAgICAgIHwKICAgIHwgIHwgICAg ICAgICAgIHwgQ29udHJvbCAgfCAgICAgICAgICAgIHw8LVJUUC9SVENQLSsgICAgKy0tLS0tLS0t LSsKICAgIHwgIHwgICAgVUEgICAgIHwgUHJvdG9jb2wgfCAgIE1lZGlhICAgIHwgfCAgICAgICAg ICAgICAgfCAgICAgICAgIHwKICAgIHwgIHxBcHBsaWNhdGlvbnw8LS0tLS0tLS0+fCAgU2VydmVy ICAgIHwgfDwtLS0tU0lQLS0tLS0+fCAgVUEtQiAgIHwKICAgIHwgIHwgIFNlcnZlciAgIHwgICAg ICAgICAgfCAgICAgICAgICAgIHw8LS0tLS1SVFAtLS0tLS0+fCAgICAgICAgIHwKICAgIHwgIHwg ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICAgIHwgfCAgICAgICAgICAgICAgKy0tLS0t LS0tLSsKICAgIHwgICstLS0tLS0tLS0tLSsgICAgICAgICAgKy0tLS0tLS0tLS0tLSsgfAogICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICArLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICBGaWd1cmUgNDogRXhh bXBsZSBvZiBTZXNzaW9uIFJlY29yZGluZyBDbGllbnQgZGVjb21wb3NpdGlvbgoKCjMuMS41LiAg SW50ZXJhY3Rpb24gd2l0aCBDb25mZXJlbmNlIEZvY3VzCgogICBJbiB0aGUgY2FzZSBvZiBhIGNl bnRyYWxpc2VkIGNvbmZlcmVuY2UgYSBjb21iaW5hdGlvbiBvZiB0aGUKICAgY29uZmVyZW5jZSBm b2N1cyBhbmQgbWl4ZXIgW1JGQzQzNTNdIG1heSBhY3QgYXMgYSBTUkMgYW5kIHRoZXJlZm9yZQog ICBwcm92aWRlIHRoZSBTUlMgd2l0aCB0aGUgcmVwbGljYXRlZCBtZWRpYSBhbmQgYXNzb2NpYXRl ZCByZWNvcmRpbmcKICAgbWV0YWRhdGEuICBJbiB0aGlzIGFycmFuZ2VtZW50IHRoZSBTUkMgaXMg YWJsZSB0byBwcm92aWRlIG1lZGlhIGFuZAogICBtZXRhZGF0YSByZWxhdGluZyB0byBlYWNoIG9m IHRoZSBwYXJ0aWNpcGFudHMsIGluY2x1ZGluZywgZm9yCiAgIGV4YW1wbGUsIGFueSBzaWRlIGNv bnZlcnNhdGlvbnMgd2hlcmUgdGhlIG1lZGlhIHBhc3NlcyB0aHJvdWdoIHRoZQogICBtaXhlci4K CiAgIENvbmZlcmVuY2UgRm9jdXMgY2FuIGVpdGhlciBwcm92aWRlIG1peGVkIHJlcGxpY2F0ZWQg bWVkaWEgb3IKICAgc2VwYXJhdGUgc3RyZWFtcyBwZXIgY29uZmVyZW5jZSBwYXJ0aWNpcGFudCAo YXMgZGVwaWN0ZWQgaW4gdGhlCiAgIEZpZ3VyZSA1KS4KCiAgIFRoZSBjb25mZXJlbmNlIGZvY3Vz IG1heSBhbHNvIGFjdCBhcyBhIFJlY29yZGluZyBBd2FyZSBVQSBpbiB0aGUgY2FzZQogICB3aGVu IG9uZSBvZiB0aGUgcGFydGljaXBhbnRzIGFjdHMgYXMgYSBTUkMuCgogICBJbiBhbiBhbHRlcm5h dGl2ZSBhcnJhbmdlbWVudCBhIFNJUCBlbmRwb2ludCB3aGljaCBpcyBhIGNvbmZlcmVuY2UKICAg cGFydGljaXBhbnQgY2FuIGFjdCBhcyBhbiBTUkMuICBUaGUgU1JDIHdpbGwgaW4gdGhpcyBjYXNl IGhhdmUgYWNjZXNzCiAgIHRvIHRoZSBtZWRpYSBhbmQgbWV0YWRhdGEgcmVsYXRpbmcgdG8gdGhh dCBwYXJ0aWN1bGFyIHBhcnRpY2lwYW50IGFuZAogICBtYXkgYmUgYWJsZSB0byBvYnRhaW4gYWRk aXRpb25hbCBtZXRhZGF0YSBmcm9tIHRoZSBjb25mZXJlbmNlIGZvY3VzLgogICBUaGUgU1JDIG1h eSBmb3IgZXhhbXBsZSB1c2UgdGhlIGNvbmZlcmVuY2UgZXZlbnQgcGFja2FnZSBhcyBkZXNjcmli ZWQKICAgaW4gW1JGQzQ1NzVdIHRvIG9idGFpbiBpbmZvcm1hdGlvbiBhYm91dCBvdGhlciBwYXJ0 aWNpcGFudHMgd2hpY2ggaXQKICAgcHJvdmlkZXMgdG8gdGhlIFNSUyB3aXRoaW4gdGhlIHJlY29y ZGluZyBtZXRhZGF0YS4KCiAgIFRoZSBTUkMgbWF5IGJlIGludm9sdmVkIGluIHRoZSBjb25mZXJl bmNlIGZyb20gdGhlIHZlcnkgYmVnaW5uaW5nIG9yCiAgIG1heSBqb2luIGF0IHNvbWUgbGF0ZXIg cG9pbnQgb2YgdGltZS4KCgoKCkh1dHRvbiwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1i ZXIgMSwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSA5XQoMCkludGVybmV0LURyYWZ0ICAgICAg QXJjaGl0ZWN0dXJlIGZvciBNZWRpYSBSZWNvcmRpbmcgICAgICAgICAgICBNYXkgMjAxMgoKCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVXNlciAxCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICArLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg ICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICB8CiAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8UGFydGljaXBhbnR8CiAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICAgICAxICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0rCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgXiBeU0lQCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBS VFAgfCB8RGlhbG9nCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCB8MQogICAgICAg VXNlciAyICAgICAgICAgICAgICAgICAgIFYgViAgICAgICBSZWNvcmRpbmcKICAgICstLS0tLS0t LS0tLSsgICAgICAgICAgICstLS0tLS0tLS0tLSsgIFNlc3Npb24gICAgICoqKioqKioqKioqKioK ICAgIHwgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAgIHw8LS0tLS0tLS0tLS0tPiog ICAgICAgICAgICoKICAgIHwgICAgICAgICAgIHw8LS0gUlRQIC0tPnwgICAgICAgICAgIHw8LVJU UC9SVENQIDEtPiogICAgICAgICAgICoKICAgIHxQYXJ0aWNpcGFudHw8LS0tLS0tLS0tPnwgRm9j dXMvU1JDIHw8LVJUUC9SVENQIDItPiogICAgU1JTICAgICoKICAgIHwgICAgIDIgICAgIHwgIFNJ UCAgICAgIHwgICAgICAgICAgIHw8LVJUUC9SVENQIDMtPiogICAgICAgICAgICoKICAgIHwgICAg ICAgICAgIHwgIERpYWxvZyAgIHwgICAgICAgICAgIHwgICAgICAgICAgICAgICogICAgICAgICAg ICoKICAgICstLS0tLS0tLS0tLSsgIDIgICAgICAgICstLS0tLS0tLS0tLSsgICAgICAgICAgICAg ICoqKioqKioqKioqKioKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXiBeCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgfFNJUAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFJUUCB8IHxEaWFsb2cKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCB8 MwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWIFYKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICstLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwKICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHxQYXJ0aWNpcGFudHwKICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgMyAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLSsKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFVzZXIgMwoKICAgICAgICAgICBGaWd1cmUgNTogQ29uZmVy ZW5jZSBGb2N1cyBhY3RpbmcgYXMgYW4gU1JDLgoKCjMuMi4gIEVzdGFibGlzaGluZyB0aGUgUmVj b3JkaW5nIFNlc3Npb24KCiAgIFRoZSBTZXNzaW9uIFJlY29yZGluZyBDbGllbnQgb3IgdGhlIFNl c3Npb24gUmVjb3JkaW5nIFNlcnZlciBtYXkKICAgaW5pdGlhdGUgdGhlIFJlY29yZGluZyBTZXNz aW9uLgoKICAgSXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQgdGhlIFJlY29yZGluZyBTZXNzaW9uIGlz IGluZGVwZW5kZW50IGZyb20gdGhlCiAgIENvbW11bmljYXRpb24gU2Vzc2lvbiB0aGF0IGlzIGJl aW5nIHJlY29yZGVkIGF0IGJvdGggdGhlIFNJUCBkaWFsb2cKICAgbGV2ZWwgYW5kIGF0IHRoZSBz ZXNzaW9uIGxldmVsLgoKICAgQ29uY2VybmluZyBtZWRpYSBuZWdvdGlhdGlvbiwgcmVndWxhciBT SVAvU0RQIGNhcGFiaWxpdGllcyBzaG91bGQgYmUKICAgdXNlZCwgYW5kIGV4aXN0aW5nIHRyYW5z Y29kaW5nIGNhcGFiaWxpdGllcyBhbmQgbWVkaWEgZW5jcnlwdGlvbgogICBzaG91bGQgbm90IGJl IHByZWNsdWRlZC4KCgoKSHV0dG9uLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAx LCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgMTBdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBBcmNo aXRlY3R1cmUgZm9yIE1lZGlhIFJlY29yZGluZyAgICAgICAgICAgIE1heSAyMDEyCgoKMy4yLjEu ICBTZXNzaW9uIFJlY29yZGluZyBDbGllbnQgSW5pdGlhdGVkIFJlY29yZGluZwoKICAgV2hlbiB0 aGUgU2Vzc2lvbiBSZWNvcmRpbmcgQ2xpZW50IGluaXRpYXRlcyB0aGUgUmVjb3JkaW5nIFNlc3Np b24gZm9yCiAgIHRoZSBwdXJwb3NlIG9mIGNvbnZleWluZyBtZWRpYSB0byB0aGUgU2Vzc2lvbiBS ZWNvcmRpbmcgU2VydmVyIGl0CiAgIHBlcmZvcm1zIHRoZSBmb2xsb3dpbmcgYWN0aW9ucy4KCiAg IG8gIFRoZSBTUkMgaXMgcHJvdmlzaW9uZWQgd2l0aCBhIFVuaWZpZWQgUmVzb3VyY2UgSWRlbnRp ZmllciAoVVJJKQogICAgICBmb3IgdGhlIFNSUywgd2hpY2ggaXMgcmVzb2x2ZWQgdGhyb3VnaCBu b3JtYWwgW1JGQzMyNjNdCiAgICAgIHByb2NlZHVyZXMuCgogICBvICBJbml0aWF0ZXMgdGhlIGRp YWxvZyBieSBzZW5kaW5nIGFuIElOVklURSByZXF1ZXN0IHRvIHRoZSBTZXNzaW9uCiAgICAgIFJl Y29yZGluZyBTZXJ2ZXIuICBUaGUgZGlhbG9nIGlzIGVzdGFibGlzaGVkIGFjY29yZGluZyB0byB0 aGUKICAgICAgbm9ybWFsIHByb2NlZHVyZXMgZm9yIGVzdGFibGlzaGluZyBhbiBJTlZJVEUgaW5p dGlhdGVkIGRpYWxvZyBhcwogICAgICBzcGVjaWZpZWQgaW4gW1JGQzMyNjFdLgoKICAgbyAgSW5j bHVkZSBpbiB0aGUgSU5WSVRFIGFuIGluZGljYXRpb24gdGhhdCB0aGUgc2Vzc2lvbiBpcwogICAg ICBlc3RhYmxpc2hlZCBmb3IgdGhlIHB1cnBvc2Ugb2YgcmVjb3JkaW5nIHRoZSBhc3NvY2lhdGVk IG1lZGlhLgoKICAgbyAgSWYgdGhlIFJlcGxpY2F0ZWQgTWVkaWEgaXMgdG8gYmUgc3RhcnRlZCBp bW1lZGlhdGVseSB0aGVuIHRoZQogICAgICBTZXNzaW9uIFJlY29yZGluZyBDbGllbnQgd2lsbCBp bmNsdWRlIGFuIFNEUCBhdHRyaWJ1dGUgb2YKICAgICAgImE9c2VuZG9ubHkiIGZvciBlYWNoIG1l ZGlhIGxpbmUgb3IgImE9aW5hY3RpdmUiIGlmIGl0IGlzIG5vdAogICAgICByZWFkeSB0byB0cmFu c21pdCB0aGUgbWVkaWEuCgogICBvICBUaGUgUmVjb3JkaW5nIFNlc3Npb24gbWF5IHJlcGxpY2F0 ZSBhbGwgbWVkaWEgYXNzb2NpYXRlZCB3aXRoIHRoZQogICAgICBDb21tdW5pY2F0aW9uIFNlc3Np b24gb3Igb25seSBhIHN1YnNldC4KCiAgIG8gIFJlcGxpY2F0ZSB0aGUgbWVkaWEgc3RyZWFtcyB0 aGF0IGFyZSB0byBiZSByZWNvcmRlZCBhbmQgdHJhbnNtaXQKICAgICAgdGhlIG1lZGlhIHRvIHRo ZSBTZXNzaW9uIFJlY29yZGluZyBTZXJ2ZXIuCgozLjIuMi4gIFNlc3Npb24gUmVjb3JkaW5nIFNl cnZlciBJbml0aWF0ZWQgUmVjb3JkaW5nCgogICBXaGVuIHRoZSBTZXNzaW9uIFJlY29yZGluZyBT ZXJ2ZXIgaW5pdGlhdGVzIHRoZSBtZWRpYSByZWNvcmRpbmcKICAgc2Vzc2lvbiB3aXRoIHRoZSBT ZXNzaW9uIFJlY29yZGluZyBDbGllbnQgaXQgcGVyZm9ybXMgdGhlIGZvbGxvd2luZwogICBhY3Rp b25zLgoKICAgbyAgVGhlIFNSUyBpcyBwcm92aXNpb25lZCB3aXRoIGEgVW5pZmllZCBSZXNvdXJj ZSBJZGVudGlmaWVyIChVUkkpCiAgICAgIGZvciB0aGUgU1JDLCB3aGljaCBpcyByZXNvbHZlZCB0 aHJvdWdoIG5vcm1hbCBbUkZDMzI2M10KICAgICAgcHJvY2VkdXJlcy4KCiAgIG8gIFNlbmQgYW4g SU5WSVRFIHJlcXVlc3QgdG8gdGhlIFNlc3Npb24gUmVjb3JkaW5nIENsaWVudAoKICAgbyAgSW5j bHVkZSBpbiB0aGUgSU5WSVRFIGFuIGluZGljYXRpb24gdGhhdCB0aGUgc2Vzc2lvbiBpcwogICAg ICBlc3RhYmxpc2hlZCBmb3IgdGhlIHB1cnBvc2Ugb2YgcmVjb3JkaW5nIHRoZSBhc3NvY2lhdGVk IG1lZGlhLgogICAgICBQb3NzaWJsZSBtZWNoYW5pc21zIGZvciB0aGlzIGluY2x1ZGUgdXNpbmcg dGhlIFJlcXVpcmUgaGVhZGVyIG9yIGEKICAgICAgbWVkaWEgZmVhdHVyZSB0YWcgYXMgZGVmaW5l ZCBpbiBbUkZDMzg0MF0uCgogICBvICBJZGVudGlmeSB0aGUgc2Vzc2lvbiB0aGF0IGlzIHRvIGJl IHJlY29yZGVkLiAgVGhlIGFjdHVhbCBtZWNoYW5pc20KICAgICAgb2YgdGhlIGlkZW50aWZpY2F0 aW9uIGRlcGVuZHMgb24gU1JDIHBvbGljeS4KCgoKSHV0dG9uLCBldCBhbC4gICAgICAgICAgRXhw aXJlcyBEZWNlbWJlciAxLCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgMTFdCgwKSW50ZXJuZXQt RHJhZnQgICAgICBBcmNoaXRlY3R1cmUgZm9yIE1lZGlhIFJlY29yZGluZyAgICAgICAgICAgIE1h eSAyMDEyCgoKICAgbyAgSWYgdGhlIFJlY29yZGluZyBTZXNzaW9uIGlzIHRvIGJlIHN0YXJ0ZWQg aW1tZWRpYXRlbHkgdGhlbiB0aGUKICAgICAgU2Vzc2lvbiBSZWNvcmRpbmcgQ2xpZW50IHdpbGwg aW5jbHVkZSBhbiBTRFAgYXR0cmlidXRlIG9mCiAgICAgICJhPXJlY3Zvbmx5IiBmb3IgZWFjaCBt ZWRpYSBsaW5lIG9yICJhPWluYWN0aXZlIiBpZiBpdCBpcyBub3QKICAgICAgcmVhZHkgdG8gcmVj ZWl2ZSB0aGUgbWVkaWEKCiAgIElmIHRoZSBTZXNzaW9uIFJlY29yZGluZyBTZXJ2ZXIgZG9lcyBu b3QgaGF2ZSBwcmlvciBrbm93bGVkZ2Ugb2Ygd2hhdAogICBtZWRpYSBzdHJlYW1zIGFyZSBhdmFp bGFibGUgdG8gYmUgcmVjb3JkZWQgaXQgY2FuIG1ha2UgdXNlIG9mIGFuCiAgIG9mZmVybGVzcyBJ TlZJVEUgd2hpY2ggYWxsb3dzIHRoZSBTZXNzaW9uIFJlY29yZGluZyBDbGllbnQgdG8gbWFrZQog ICB0aGUgaW5pdGlhbCBTZXNzaW9uIERlc2NyaXB0aW9uIFByb3RvY29sIChTRFApIG9mZmVyLgoK My4yLjMuICBQYXVzZS9SZXN1bWUgUmVjb3JkaW5nIFNlc3Npb24KCiAgIFRoZSBTZXNzaW9uIFJl Y29yZGluZyBTZXJ2ZXIgb3IgdGhlIFNlc3Npb24gUmVjb3JkaW5nIENsaWVudCBtYXkKICAgcGF1 c2UgdGhlIHJlY29yZGluZyBieSBjaGFuZ2luZyB0aGUgU0RQIGRpcmVjdGlvbiBhdHRyaWJ1dGUg dG8KICAgImluYWN0aXZlIiBhbmQgcmVzdW1lIHRoZSByZWNvcmRpbmcgYnkgY2hhbmdpbmcgdGhl IGRpcmVjdGlvbiBiYWNrIHRvCiAgICJyZWN2b25seSIgb3IgInNlbmRvbmx5Ii4KCjMuMi40LiAg TWVkaWEgU3RyZWFtIE1peGluZwoKICAgSW4gYSBiYXNpYyBzZXNzaW9uIGludm9sdmluZyBvbmx5 IGF1ZGlvIHRoZXJlIGFyZSB0eXBpY2FsbHkgdHdvCiAgIGF1ZGlvL1JUUCBzdHJlYW1zIGJldHdl ZW4gdGhlIHR3byBVQXMgaW52b2x2ZWQgdHJhbnNwb3J0aW5nIG1lZGlhIGluCiAgIGVhY2ggZGly ZWN0aW9uLiAgV2hlbiByZWNvcmRpbmcgdGhpcyBtZWRpYSB0aGUgdHdvIHN0cmVhbXMgbWF5IGJl CiAgIG1peGVkIGF0IHRoZSBTUkMgYmVmb3JlIGJlaW5nIHRyYW5zbWl0dGVkIHRvIHRoZSBTUlMg b3IgaXQgbWF5IGJlIGEKICAgcmVxdWlyZW1lbnQgb2YgdGhlIHJlY29yZGluZyBzZXJ2ZXIgdGhh dCB0aGUgbWVkaWEgc3RyZWFtcyBhcmUgbm90CiAgIG1peGVkIGFuZCBhcmUgc2VudCB0byB0aGUg U1JTIGFzIHR3byBzZXBhcmF0ZSBzdHJlYW1zLiAgVGhlIGNhc2Ugd2hlbgogICBtZWRpYSBpcyBt aXhlZCBhdCB0aGUgU1JDIGlzIHNpbXBsZSBhcyBvbmx5IGEgc2luZ2xlIG1lZGlhIHN0cmVhbSBp cwogICByZXF1aXJlZCB0byBiZSBzZW50IHRvIHRoZSBTUlMuICBIb3dldmVyIGluIHRoZSBjYXNl IHdoZW4gdGhlIG1lZGlhCiAgIHN0cmVhbXMgYXJlIG5vdCBtaXhlZCB0aGVuIHRoZSBTRFAgb2Zm ZXIgc2VudCB0byB0aGUgU1JTIG11c3QKICAgZGVzY3JpYmUgdHdvIHNlcGFyYXRlIG1lZGlhIHN0 cmVhbXMuCgozLjIuNS4gIE1lZGlhIFRyYW5zY29kaW5nCgogICBUaGUgY29tbXVuaWNhdGlvbiBz ZXNzaW9uIChDUykgYW5kIHRoZSByZWNvcmRpbmcgc2Vzc2lvbiAoUlMpIGFyZQogICBuZWdvdGlh dGVkIHNlcGFyYXRlbHkgdXNpbmcgYSBzdGFuZGFyZCBTRFAgb2ZmZXIvYW5zd2VyIGV4Y2hhbmdl CiAgIHdoaWNoIG1heSByZXN1bHQgaW4gdGhlIFNSQyBoYXZpbmcgdG8gcGVyZm9ybSBtZWRpYSB0 cmFuc2NvZGluZwogICBiZXR3ZWVuIHRoZSB0d28gc2Vzc2lvbnMuICBJZiB0aGUgU1JDIGlzIG5v dCBjYXBhYmxlIG9mIHBlcmZvcm1pbmcKICAgbWVkaWEgdHJhbnNjb2RpbmcgaXQgbWF5IGxpbWl0 IHRoZSBtZWRpYSBmb3JtYXRzIGluIHRoZSBvZmZlciB0byB0aGUKICAgU1JTIGRlcGVuZGluZyBv biB3aGF0IG1lZGlhIGlzIG5lZ290aWF0ZWQgb24gdGhlIENTIG9yIG1heSBsaW1pdCB3aGF0CiAg IGl0IGluY2x1ZGVzIGluIHRoZSBvZmZlciBvbiB0aGUgQ1MgaWYgaXQgaGFzIHByaW9yIGtub3ds ZWRnZSBvZiB0aGUKICAgbWVkaWEgZm9ybWF0cyBzdXBwb3J0ZWQgYnkgdGhlIFNSUy4gIEhvd2V2 ZXIgdHlwaWNhbGx5IHRoZSBTUlMgd2lsbAogICBiZSBhIG1vcmUgY2FwYWJsZSBkZXZpY2Ugd2hp Y2ggY2FuIHByb3ZpZGUgYSB3aWRlIHJhbmdlIG9mIG1lZGlhCiAgIGZvcm1hdCBvcHRpb25zIHRv IHRoZSBTUkMgYW5kIG1heSBhbHNvIGJlIGFibGUgdG8gbWFrZSB1c2Ugb2YgYSBtZWRpYQogICB0 cmFuc2NvZGVyIGFzIGRldGFpbGVkIGluIFtSRkM1MzY5XS4KCjMuMy4gIFJlY29yZGluZyBNZXRh ZGF0YQoKCgoKCgpIdXR0b24sIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDEsIDIw MTIgICAgICAgICAgICAgICBbUGFnZSAxMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgIEFyY2hpdGVj dHVyZSBmb3IgTWVkaWEgUmVjb3JkaW5nICAgICAgICAgICAgTWF5IDIwMTIKCgozLjMuMS4gIENv bnRlbnRzIG9mIHJlY29yZGluZyBtZXRhZGF0YQoKICAgVGhlIG1ldGFkYXRhIG1vZGVsIGlzIGRl ZmluZWQgaW4gW0ktRC5pZXRmLXNpcHJlYy1tZXRhZGF0YV0uCgozLjMuMi4gIE1lY2hhbmlzbXMg Zm9yIGRlbGl2ZXJ5IG9mIG1ldGFkYXRhIHRvIFNlc3Npb24gUmVjb3JkaW5nIFNlcnZlcgoKICAg VGhlIFNSUyBvYnRhaW5zIHNlc3Npb24gcmVjb3JkaW5nIG1ldGFkYXRhIGZyb20gdGhlIFNSQy4g IFRoZQogICBtZXRhZGF0YSBpcyB0cmFuc3BvcnRlZCB2aWEgU0lQIGJhc2VkIG1lY2hhbmlzbXMg YXMgc3BlY2lmaWVkIGluCiAgIFtJLUQuaWV0Zi1zaXByZWMtcHJvdG9jb2xdCgogICBJdCBpcyBh bHNvIHBvc3NpYmxlIHRoYXQgbWV0YWRhdGEgaXMgdHJhbnNwb3J0ZWQgdmlhIG5vbiBTSVAgYmFz ZWQKICAgbWVjaGFuaXNtcyBidXQgdGhlc2UgYXJlIGNvbnNpZGVyZWQgb3V0IG9mIHNjb3BlLgoK ICAgSXQgaXMgYWxzbyBwb3NzaWJsZSB0byBoYXZlIFJTIHNlc3Npb24gd2l0aG91dCB0aGUgbWV0 YWRhdGEsIGluIHN1Y2gKICAgY2FzZSBTUlMgd2lsbCBiZSByZWNlaXZpbmcgaXQgYnkgc29tZSBv dGhlciBtZWFucyBvciBub3QgYXQgYWxsLgoKMy40LiAgTm90aWZpY2F0aW9ucyB0byB0aGUgUmVj b3JkZWQgVXNlciBBZ2VudHMKCiAgIFR5cGljYWxseSBhIHVzZXIgdGhhdCBpcyBpbnZvbHZlZCBp biBhIHNlc3Npb24gdGhhdCBpcyB0byBiZSByZWNvcmRlZAogICBpcyBub3RpZmllZCBieSBhbiBh bm5vdW5jZW1lbnQgYXQgdGhlIGJlZ2lubmluZyBvZiB0aGUgc2Vzc2lvbiBvciBtYXkKICAgcmVj ZWl2ZSBzb21lIHdhcm5pbmcgdG9uZXMgd2l0aGluIHRoZSBtZWRpYS4gIEhvd2V2ZXIgdGhlCiAg IHN0YW5kYXJkaXphdGlvbiBvZiBtZWRpYSByZWNvcmRpbmcgcHJvdG9jb2xzIHdoZW4gdXNpbmcg U0lQIGVuYWJsZSBhbgogICBpbmRpY2F0aW9uIHRoYXQgdGhlIGNhbGwgaXMgYmVpbmcgcmVjb3Jk ZWQgdG8gYmUgaW5jbHVkZWQgaW4gdGhlIFNJUAogICByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzIGFz c29jaWF0ZWQgd2l0aCB0aGF0IGNvbW11bmljYXRpb24gc2Vzc2lvbi4KCiAgIEl0IGlzIHRoZSBT ZXNzaW9uIFJlY29yZGluZyBDbGllbnQgdGhhdCBwcm92aWRlcyB0aGUgbm90aWZpY2F0aW9uIHRv CiAgIGFsbCBTSVAgVUFzIGZvciB3aGljaCBpdCBpcyByZXBsaWNhdGluZyByZWNlaXZlZCBtZWRp YSBmb3IgdGhlCiAgIHB1cnBvc2Ugb2YgcmVjb3JkaW5nIGluY2x1ZGluZyB0aGUgbG9jYWwgdXNl ciBpZiB0aGUgU2Vzc2lvbgogICBSZWNvcmRpbmcgQ2xpZW50IGlzIGEgU0lQIGVuZHBvaW50LgoK My41LiAgUHJldmVudGluZyB0aGUgcmVjb3JkaW5nIG9mIGEgU0lQIHNlc3Npb24KCiAgIEEgUmVj b3JkaW5nIEF3YXJlIFVBIG1heSBkdXJpbmcgdGhlIGluaXRpYWwgc2Vzc2lvbiBlc3RhYmxpc2ht ZW50IG9yCiAgIGR1cmluZyBhbiBlc3RhYmxpc2hlZCBzZXNzaW9uIHByb3ZpZGUgYW4gaW5kaWNh dGlvbiBvZiB0aGVpcgogICBwcmVmZXJlbmNlIHdpdGggcmVnYXJkIHRvIHJlY29yZGluZyB0aGUg bWVkaWEgaW4gdGhlIGNvbW11bmljYXRpb24KICAgc2Vzc2lvbi4gIFRoZSBtZWNoYW5pc20gZm9y IHRoaXMgYXJlIHNwZWNpZmllZCBpbgogICBbSS1ELmlldGYtc2lwcmVjLXByb3RvY29sXQoKCjQu ICBJQU5BIGNvbnNpZGVyYXRpb25zCgogICBUaGlzIGRyYWZ0IG1lbnRpb25zIFNJUC9TRFAgZXh0 ZW5zaW9ucy4gIFRoZSBhc3NvY2lhdGVkIElBTkEKICAgY29uc2lkZXJhdGlvbnMgYXJlIGFkZHJl c3NlZCBpbiBbSS1ELmlldGYtc2lwcmVjLXByb3RvY29sXSB0aGF0CiAgIGRlZmluZXMgdGhlbS4K CgoKCgoKCkh1dHRvbiwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMSwgMjAxMiAg ICAgICAgICAgICAgIFtQYWdlIDEzXQoMCkludGVybmV0LURyYWZ0ICAgICAgQXJjaGl0ZWN0dXJl IGZvciBNZWRpYSBSZWNvcmRpbmcgICAgICAgICAgICBNYXkgMjAxMgoKCjUuICBTZWN1cml0eSBj b25zaWRlcmF0aW9ucwoKICAgVGhlIFJlY29yZGluZyBTZXNzaW9uIGlzIGZ1bmRhbWVudGFsbHkg YSBzdGFuZGFyZCBTSVAgZGlhbG9nIGFuZAogICBtZWRpYSBzZXNzaW9uIGFuZCB0aGVyZWZvcmUg bWFrZXMgdXNlIG9mIGV4aXN0aW5nIFNJUCBzZWN1cml0eQogICBtZWNoYW5pc21zIGZvciBzZWN1 cmluZyB0aGUgUmVjb3JkaW5nIFNlc3Npb24gYW5kIFJlY29yZGluZyBNZXRhZGF0YS4KCiAgIFRo ZSBpbnRlbmRlZCB1c2Ugb2YgdGhpcyBhcmNoaXRlY3R1cmUgaXMgb25seSBmb3IgdGhlIGNhc2Ug d2hlcmUgdGhlCiAgIHVzZXJzIGFyZSBhd2FyZSB0aGF0IHRoZXkgYXJlIGJlaW5nIHJlY29yZGVk LCBhbmQgdGhlIGFyY2hpdGVjdHVyZQogICBwcm92aWRlcyB0aGUgbWVhbnMgZm9yIHRoZSBTZXNz aW9uIFJlY29yZGluZyBDbGllbnQgdG8gbm90aWZ5IHVzZXJzCiAgIHRoYXQgdGhleSBhcmUgYmVp bmcgcmVjb3JkZWQuCgogICBUaGlzIGFyY2hpdGVjdHVyYWwgc29sdXRpb24gaXMgbm90IGludGVu ZGVkIHRvIHN1cHBvcnQgbGF3ZnVsCiAgIGludGVyY2VwdCB3aGljaCBpbiBjb250cmFzdCByZXF1 aXJlcyB0aGF0IHVzZXJzIGFyZSBub3QgaW5mb3JtZWQuCgogICBJdCBpcyB0aGUgcmVzcG9uc2li aWxpdHkgb2YgdGhlIFNlc3Npb24gUmVjb3JkaW5nIFNlcnZlciB0byBwcm90ZWN0CiAgIHRoZSBS ZXBsaWNhdGVkIE1lZGlhIGFuZCBSZWNvcmRpbmcgTWV0YWRhdGEgb25jZSBpdCBoYXMgYmVlbiBy ZWNlaXZlZAogICBhbmQgYXJjaGl2ZWQuCgoKNi4gIEFja25vd2xlZGdlbWVudHMKCiAgIFRoYW5r cyB0byBKb2huIEVsd2VsbCwgQWxhbiBKb2huc29uLCBDdWxsZW4gSmVubmluZ3MsIEhhZHJpZWwg S2FwbGFuLAogICBIZW5yeSBMdW0sIFBhdWwgS3l6aXZhdCwgUGFydGhhc2FyYXRoaSBSLCBSYW0g TW9oYW4gUiwgQ2hhcmxlcyBFY2tlbAogICBhbmQgRnJpc28gRmVlbnN0cmEgZm9yIHRoZWlyIHNp Z25pZmljYW50IGNvbnRyaWJ1dGlvbnMgYW5kIGFzc2lzdGFuY2UKICAgd2l0aCB0aGlzIGRvY3Vt ZW50IGFuZCBXb3JraW5nIEdyb3VwLCBhbmQgdG8gYWxsIHRoZSBtZW1iZXJzIG9mCiAgIFNJUFJF QyBXRyBtYWlsaW5nIGxpc3QgZm9yIHByb3ZpZGluZyB2YWx1YWJsZSBpbnB1dCB0byB0aGlzIHdv cmsuCgoKNy4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtSRkMzMjYxXSAgUm9zZW5iZXJn LCBKLiwgU2NodWx6cmlubmUsIEguLCBDYW1hcmlsbG8sIEcuLCBKb2huc3RvbiwKICAgICAgICAg ICAgICBBLiwgUGV0ZXJzb24sIEouLCBTcGFya3MsIFIuLCBIYW5kbGV5LCBNLiwgYW5kIEUuCiAg ICAgICAgICAgICAgU2Nob29sZXIsICJTSVA6IFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCIs IFJGQyAzMjYxLAogICAgICAgICAgICAgIEp1bmUgMjAwMi4KCiAgIFtSRkMzMjYzXSAgUm9zZW5i ZXJnLCBKLiBhbmQgSC4gU2NodWx6cmlubmUsICJTZXNzaW9uIEluaXRpYXRpb24KICAgICAgICAg ICAgICBQcm90b2NvbCAoU0lQKTogTG9jYXRpbmcgU0lQIFNlcnZlcnMiLCBSRkMgMzI2MywKICAg ICAgICAgICAgICBKdW5lIDIwMDIuCgogICBbUkZDNDU2Nl0gIEhhbmRsZXksIE0uLCBKYWNvYnNv biwgVi4sIGFuZCBDLiBQZXJraW5zLCAiU0RQOiBTZXNzaW9uCiAgICAgICAgICAgICAgRGVzY3Jp cHRpb24gUHJvdG9jb2wiLCBSRkMgNDU2NiwgSnVseSAyMDA2LgoKICAgW1JGQzYzNDFdICBSZWhv ciwgSy4sIFBvcnRtYW4sIEwuLCBIdXR0b24sIEEuLCBhbmQgUi4gSmFpbiwgIlVzZQogICAgICAg ICAgICAgIENhc2VzIGFuZCBSZXF1aXJlbWVudHMgZm9yIFNJUC1CYXNlZCBNZWRpYSBSZWNvcmRp bmcKICAgICAgICAgICAgICAoU0lQUkVDKSIsIFJGQyA2MzQxLCBBdWd1c3QgMjAxMS4KCiAgIFtJ LUQuaWV0Zi1zaXByZWMtbWV0YWRhdGFdCiAgICAgICAgICAgICAgUiwgUi4sIFJhdmluZHJhbiwg UC4sIGFuZCBQLiBLeXppdmF0LCAiU2Vzc2lvbiBJbml0aWF0aW9uCgoKCkh1dHRvbiwgZXQgYWwu ICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMSwgMjAxMiAgICAgICAgICAgICAgIFtQYWdlIDE0 XQoMCkludGVybmV0LURyYWZ0ICAgICAgQXJjaGl0ZWN0dXJlIGZvciBNZWRpYSBSZWNvcmRpbmcg ICAgICAgICAgICBNYXkgMjAxMgoKCiAgICAgICAgICAgICAgUHJvdG9jb2wgKFNJUCkgUmVjb3Jk aW5nIE1ldGFkYXRhIiwKICAgICAgICAgICAgICBkcmFmdC1pZXRmLXNpcHJlYy1tZXRhZGF0YS0w NiAod29yayBpbiBwcm9ncmVzcyksCiAgICAgICAgICAgICAgTWFyY2ggMjAxMi4KCiAgIFtJLUQu aWV0Zi1zaXByZWMtcHJvdG9jb2xdCiAgICAgICAgICAgICAgUG9ydG1hbiwgTC4sIEx1bSwgSC4s IEVja2VsLCBDLiwgSm9obnN0b24sIEEuLCBhbmQgQS4KICAgICAgICAgICAgICBIdXR0b24sICJT ZXNzaW9uIFJlY29yZGluZyBQcm90b2NvbCIsCiAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1zaXBy ZWMtcHJvdG9jb2wtMDQgKHdvcmsgaW4gcHJvZ3Jlc3MpLAogICAgICAgICAgICAgIE1heSAyMDEy LgoKICAgW1JGQzMyNjVdICBSb2FjaCwgQS4sICJTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wg KFNJUCktU3BlY2lmaWMKICAgICAgICAgICAgICBFdmVudCBOb3RpZmljYXRpb24iLCBSRkMgMzI2 NSwgSnVuZSAyMDAyLgoKICAgW1JGQzM4NDBdICBSb3NlbmJlcmcsIEouLCBTY2h1bHpyaW5uZSwg SC4sIGFuZCBQLiBLeXppdmF0LAogICAgICAgICAgICAgICJJbmRpY2F0aW5nIFVzZXIgQWdlbnQg Q2FwYWJpbGl0aWVzIGluIHRoZSBTZXNzaW9uCiAgICAgICAgICAgICAgSW5pdGlhdGlvbiBQcm90 b2NvbCAoU0lQKSIsIFJGQyAzODQwLCBBdWd1c3QgMjAwNC4KCiAgIFtSRkM0MzUzXSAgUm9zZW5i ZXJnLCBKLiwgIkEgRnJhbWV3b3JrIGZvciBDb25mZXJlbmNpbmcgd2l0aCB0aGUKICAgICAgICAg ICAgICBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkiLCBSRkMgNDM1MywKICAgICAg ICAgICAgICBGZWJydWFyeSAyMDA2LgoKICAgW1JGQzQ1NzVdICBSb3NlbmJlcmcsIEouLCBTY2h1 bHpyaW5uZSwgSC4sIGFuZCBPLiBMZXZpbiwgIkEgU2Vzc2lvbgogICAgICAgICAgICAgIEluaXRp YXRpb24gUHJvdG9jb2wgKFNJUCkgRXZlbnQgUGFja2FnZSBmb3IgQ29uZmVyZW5jZQogICAgICAg ICAgICAgIFN0YXRlIiwgUkZDIDQ1NzUsIEF1Z3VzdCAyMDA2LgoKICAgW1JGQzU1NjddICBNZWxh bmNodWssIFQuLCAiQW4gQXJjaGl0ZWN0dXJhbCBGcmFtZXdvcmsgZm9yIE1lZGlhCiAgICAgICAg ICAgICAgU2VydmVyIENvbnRyb2wiLCBSRkMgNTU2NywgSnVuZSAyMDA5LgoKICAgW1JGQzUzNjld ICBDYW1hcmlsbG8sIEcuLCAiRnJhbWV3b3JrIGZvciBUcmFuc2NvZGluZyB3aXRoIHRoZSBTZXNz aW9uCiAgICAgICAgICAgICAgSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSIsIFJGQyA1MzY5LCBP Y3RvYmVyIDIwMDguCgogICBbUkZDMjgwNF0gIElBQiBhbmQgSUVTRywgIklFVEYgUG9saWN5IG9u IFdpcmV0YXBwaW5nIiwgUkZDIDI4MDQsCiAgICAgICAgICAgICAgTWF5IDIwMDAuCgoKQXV0aG9y cycgQWRkcmVzc2VzCgogICBBbmRyZXcgSHV0dG9uIChlZGl0b3IpCiAgIFNpZW1lbnMgRW50ZXJw cmlzZSBDb21tdW5pY2F0aW9ucwogICBIb2ZtYW5uc3RyYXNzZSA1MQogICBNdW5pY2ggRC04MTM3 OQogICBHZXJtYW55CgogICBFbWFpbDogIGFuZHJldy5odXR0b25Ac2llbWVucy1lbnRlcnByaXNl LmNvbQoKCgoKCgoKSHV0dG9uLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAxLCAy MDEyICAgICAgICAgICAgICAgW1BhZ2UgMTVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBBcmNoaXRl Y3R1cmUgZm9yIE1lZGlhIFJlY29yZGluZyAgICAgICAgICAgIE1heSAyMDEyCgoKICAgTGVvbiBQ b3J0bWFuIChlZGl0b3IpCiAgIE5pY2UgU3lzdGVtcwogICA4IEhhcG5pbmEKICAgUmEnYW5hbmEg IDQzMDE3CiAgIElzcmFlbAoKICAgRW1haWw6ICBsZW9uLnBvcnRtYW5AbmljZS5jb20KCgogICBS YWpuaXNoIEphaW4KICAgSVBDIFN5c3RlbXMKICAgNzc3IENvbW1lcmNlIERyaXZlCiAgIEZhaXJm aWVsZCwgQ1QgIDA2ODI1CiAgIFVTQQoKICAgRW1haWw6ICByYWpuaXNoLmphaW5AaXBjLmNvbQoK CiAgIEtlbiBSZWhvcgogICBDaXNjbyBTeXN0ZW1zLCBJbmMuCiAgIDE3MCBXZXN0IFRhc21hbiBE cml2ZQogICBTYW4gSm9zZSwgQ0EgIDk1MTM0LTE3MDYKICAgVVNBCgogICBFbWFpbDogIGtyZWhv ckBjaXNjby5jb20KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpIdXR0b24sIGV0IGFsLiAgICAg ICAgICBFeHBpcmVzIERlY2VtYmVyIDEsIDIwMTIgICAgICAgICAgICAgICBbUGFnZSAxNl0KDAo= --_004_07465C1D981ABC41A344374066AE1A2C3A7AEB818BTLVMBX01nicec_-- From internet-drafts@ietf.org Wed May 30 05:39: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 33A5821F8658; Wed, 30 May 2012 05:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 IVgJK8D1Y2-v; Wed, 30 May 2012 05:39:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFF221F8573; Wed, 30 May 2012 05:39:23 -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.02 Message-ID: <20120530123923.24516.94530.idtracker@ietfa.amsl.com> Date: Wed, 30 May 2012 05:39:23 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-architecture-05.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 12:39:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Recording Working Group of the IE= TF. Title : An Architecture for Media Recording using the Session In= itiation Protocol Author(s) : Andrew Hutton Leon Portman Rajnish Jain Ken Rehor Filename : draft-ietf-siprec-architecture-05.txt Pages : 16 Date : 2012-05-30 Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes architectures for deploying session recording solutions in an environment which is based on the Session Initiation Protocol (SIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-siprec-architecture-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-architecture-05.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-siprec-architecture/ From miguel.a.garcia@ericsson.com Wed May 30 05:44: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 0B8B821F8650 for ; Wed, 30 May 2012 05:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[AWL=-2.086, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=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 KYnL8RXLZIgg for ; Wed, 30 May 2012 05:44:34 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 63F3321F85CC for ; Wed, 30 May 2012 05:44:33 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc66d000006fdc-cc-4fc61630c6db Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 5A.52.28636.03616CF4; Wed, 30 May 2012 14:44:32 +0200 (CEST) Received: from [159.107.24.205] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.0; Wed, 30 May 2012 14:44:31 +0200 Message-ID: <4FC6162E.9000304@ericsson.com> Date: Wed, 30 May 2012 14:44:30 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Hutton, Andrew" References: <4E6F1A63.1000202@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF013D86@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF013D86@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUyM+Jvra6B2DF/gze9ChYzW1tZLM72dbFb PL0/jc3i/QVdi2033rBZnDg+n9XiaNNrdgd2j/vf/rJ7TPm9kdVj6dsONo+ds+6yeyxZ8pPJ o+PCCyaPG7ffMwewR3HZpKTmZJalFunbJXBlHNx9kKVggkXFlXeLGRsYn2h1MXJySAiYSEx6 s4kJwhaTuHBvPVsXIxeHkMApRomVR08yQjhrGCWeP37ICFLFK6At8XDXWTCbRUBV4vPyPjYQ m03AXKJ140Z2EFtUIFhiXvdNFoh6QYmTM5+A2SIC1hIf5rcwgwxlFljIJPHp/kqwQcICVhLP 7/4GKxISyJG42/ENLM4p4CtxavEvMJtZwFbiwpzrLBC2vMT2t3OYIeo1JSbfXMo8gVFwFpJ9 s5C0zELSsoCReRWjcG5iZk56uaFealFmcnFxfp5eceomRmBEHNzyW3cH46lzIocYpTlYlMR5 uZL2+wsJpCeWpGanphakFsUXleakFh9iZOLglGpg1AjekWt3fVNlY/uhU9fZPvc+UeHc/o01 6v/PzZ/PXH75YY3v/CsrpW9wKNyq2hMbF1XisWNesulsm4uK+8JtFeeyf+JJ1l9ySv5RdoGc yF2H618PWgdYv+ze+fa6da8/950bHQ5qPHs4guZu/XDpp47l2XiVY74H5Bu//vMrvyjxn9F6 UYsAtxJLcUaioRZzUXEiACXdSH9WAgAA Cc: "fandreas@cisco.com" , "siprec@ietf.org" Subject: Re: [siprec] SDP Comments to draft-ietf-siprec-protocol-00 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, 30 May 2012 12:44:35 -0000 Ok, so we will wait for the document to enter WGLC and at that time we will organize a review. Please inform us when we need to kick the SDP directorate review. BR, Miguel On 30/05/2012 13:21, Hutton, Andrew wrote: > Hi Miguel, > > I checked whether your comments had been taken care of in the latest version of draft-ietf-siprec-protocol and found that mostly they have apart from a couple of minor omissions. See the text below for my analysis. > > Regarding getting the SDP directorate to review the draft then given your previous review I think we can wait until the draft is at WGLC before we ask for a review by the SDP directorate. This I hope will not be long probably following Vancouver. > > Henry, Could you please take care of the outstanding issues below as you have the pen. > > Regards > Andy > > > >> -----Original Message----- >> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >> Sent: 13 September 2011 09:55 >> To: leon.portman@nice.com; henry.lum@genesyslab.com; >> alan.b.johnston@gmail.com; Hutton, Andrew; siprec@ietf.org; mmusic >> Cc: Elwell, John; Brian Rosen >> Subject: SDP Comments to draft-ietf-siprec-protocol-00 >> >> Hi, >> >> here are some comments to the SDP in draft-ietf-siprec-protocol-00 >> >> - Section 5.3. I found a few "must" and "should" in lowercase. I wonder >> whether these should be written normatively (uppercase) or is there a >> reason for not doing it, in which case, I would recommend to go around >> the lowercase terms to avoid confusion. > > Done > >> >> - Section 5.3, third paragraph: the text is written around the format >> (a=sendonly), but I will instead put the focus on the semantics. For >> example, I would write: >> >> Since the SRC does not expect to receive media from the SRS, the >> SRC >> will typically set each media stream of the SDP offer to only send >> media, >> by qualifying them with the a=sendonly attribute. Conversely, as the >> SRS >> only receives RTP streams from SRCs, the SDP answer will normally set >> each media stream to only receive media, by setting them with the >> a=recvonly attribute, according to the procedures of RFC 3264 >> [RFC3264]. > > > Partly Done - The SDP answer part being set to a=recvonly is not in the current draft and could be added. > > >> >> - Section 5.3, fourth paragraph. As a matter of personal taste, I >> prefer >> that actions are attributed to either the SRC or the SRS, but not to >> the >> "SDP" (which is not an entity). For example, the sentence "the SDP must >> provide a label..." should be restated in terms of the "the SRC MUST >> include a label *attribute* (a=label) in each media stream of the >> SDP"... > > Done > > >> >> Also, in this fourth paragraph in Section 5.3, avoid the future tense, >> unless you really want to describe an action that will take a later >> time: >> "... will be used ..." > > Done > > >> >> - Figure 4 in Section 5.3: the "o=" line is incorrect, due to sess-id >> and >> sess-version are set to 0. Also, the selected IP address is not being >> according to RFC 5737. Use this one instead: >> >> >> o=SRS 2890844526 2890844526 IN IP4 198.51.100.1 > > Done > >> >> - Figure 4 in Section 5.3: the "s=" line is incorrect according to RFC >> 3264. Use an white space or dash character instead: >> >> s=- > > Done >> >> - Figure 4 in Section 5.3: the "c=" line is incorrect due to the IP >> address not being according to RFC 5737. Use this one instead (should >> be >> the same IP address as in the o= line). >> >> c=IN IP4 198.51.100.1 > > Done > >> >> - Figure 4 in Section 5.3: all the m= lines are incorrect. All the >> lines >> should indicate an even port number for RTP, implicitly indicating that >> the consecutive port number is used for RTCP. Additionally, two lines >> referring to the H264 codec indicate that the stream is of type >> "audio", >> which is incorrect. Use the following "m=" lines (in order). >> >> m=audio 12240 RTP/AVP 0 4 8 >> m=video 22456 RTP/AVP 98 >> m=audio 12242 RTP/AVP 0 4 8 >> m=video 22458 RTP/AVP 98 > > The 4th m-line still incorrectly indicates it is audio - Needs to be fixed. > >> >> - Figure 4 in Section 5.3. Use a correct a=fmtp line, for example: >> >> a=fmtp:98 profile-level-id=42A01E; >> sprop-parameter-sets=Z0IACpZTBYmI,aMljiA== > > Done. > > >> >> >> - Section 5.3, 5th and 6th paragraphs: The text should be stated in >> terms >> of SDP offer/answer (we are in Section 5.3, which is "SDP handling"), >> and >> a reference to RFC 3264 should be added. Therefore: >> >> To remove a recorded media stream from the recording session, the >> SRC >> sends a new SDP offer where the port of the media stream to be >> removed is set to zero, according to the procedures in RFC 3264 >> [RFC3264]. >> >> To add a new media stream to the recording session, the SRC sends a >> new SDP offer adding a new media stream description in an m= line, >> according to the procedures in RFC 3264 [RFC3264]. > > Done > >> >> - Section 5.3, 7th paragraph should also be drafted in terms of SDP >> O/A. >> >> - Figure 6 in Section 5.4, use this SDP instead: >> >> v=0 >> o=SRS 2890844526 2890844526 IN IP4 198.51.100.1 >> s=- >> c=IN IP4 198.51.100.1 >> t=0 0 >> m=audio 12240 RTP/AVP 0 4 8 >> a=sendonly >> a=label:1 >> > > Done - The SDP example has been removed. > > >> - Section 6.2.1. The syntax is not correct. You should start by >> extending >> the "attribute" production in SDP, for example: >> >> attribute /= record-attr >> ; attribute defined in RFC 4566 >> record-attr = "record:" indication >> indication = "on" / "off" / "paused" > > Done - now section 10.2.1 - But also applies to the recordpref-attr in what is now 10.1.1 so this needs to be fixed. > >> >> - Section 6.2.2. For discussion... Do you really need two attributes, >> "record" and "recordpref"? I believe both could be integrated into a >> single attribute. For example, you could have the a=record attribute >> with >> the two values, one for the current status, and one of the current >> preference. >> > > Done - Clarified on mailing list that we do need both. > >> - Section 7.1. Although this is not related to SDP, in this paragraph >> you >> need to specify the registry where you want to register the new option >> tags. I believe it is the Session Initiation Protocol Parameters >> registry. >> >> - Section 7.5.1 and 7.5.2. The registration lacks contact name, email >> address, and telephone number, according to the requirements in RFC >> 4566. >> > > Contact names and e-mail address is now included. RFC 4566 requires a telephone number but personally I think this is not desirable due to privacy issues. > >> >> /Miguel >> -- >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From Henry.Lum@genesyslab.com Wed May 30 09: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 DD1D521F859F for ; Wed, 30 May 2012 09:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.401 X-Spam-Level: X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=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 RfxL3Swa2WZh for ; Wed, 30 May 2012 09:44:49 -0700 (PDT) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [198.49.180.223]) by ietfa.amsl.com (Postfix) with ESMTP id 4177711E80BA for ; Wed, 30 May 2012 09:44:49 -0700 (PDT) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.wc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id q4UGiddw007065; Wed, 30 May 2012 09:44:40 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 May 2012 09:44:40 -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: Wed, 30 May 2012 09:44:39 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF7408938A87@NAHALD.us.int.genesyslab.com> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF013D86@MCHP04MSX.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SDP Comments to draft-ietf-siprec-protocol-00 Thread-Index: Acxx8tLJHuCEmImhT1Gldr8fzviEiTMW8mbQAA0yhvA= References: <4E6F1A63.1000202@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF013D86@MCHP04MSX.global-ad.net> From: "Henry Lum" To: "Hutton, Andrew" , "Miguel A. Garcia" X-OriginalArrivalTime: 30 May 2012 16:44:40.0625 (UTC) FILETIME=[81FF6A10:01CD3E83] Cc: fandreas@cisco.com, siprec@ietf.org Subject: Re: [siprec] SDP Comments to draft-ietf-siprec-protocol-00 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, 30 May 2012 16:44:51 -0000 Thanks for the detailed review. I will make the fixes along with the issues brought up in ietf 83. Henry > -----Original Message----- > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > Sent: May-30-12 7:21 AM > To: Miguel A. Garcia > Cc: Brian Rosen; leon.portman@nice.com; Henry Lum; alan.b.johnston@gmail.com; > fandreas@cisco.com; siprec@ietf.org > Subject: RE: SDP Comments to draft-ietf-siprec-protocol-00 >=20 > Hi Miguel, >=20 > I checked whether your comments had been taken care of in the latest version > of draft-ietf-siprec-protocol and found that mostly they have apart from a > couple of minor omissions. See the text below for my analysis. >=20 > Regarding getting the SDP directorate to review the draft then given your > previous review I think we can wait until the draft is at WGLC before we ask > for a review by the SDP directorate. This I hope will not be long probably > following Vancouver. >=20 > Henry, Could you please take care of the outstanding issues below as you have > the pen. >=20 > Regards > Andy >=20 >=20 >=20 > > -----Original Message----- > > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > > Sent: 13 September 2011 09:55 > > To: leon.portman@nice.com; henry.lum@genesyslab.com; > > alan.b.johnston@gmail.com; Hutton, Andrew; siprec@ietf.org; mmusic > > Cc: Elwell, John; Brian Rosen > > Subject: SDP Comments to draft-ietf-siprec-protocol-00 > > > > Hi, > > > > here are some comments to the SDP in draft-ietf-siprec-protocol-00 > > > > - Section 5.3. I found a few "must" and "should" in lowercase. I wonder > > whether these should be written normatively (uppercase) or is there a > > reason for not doing it, in which case, I would recommend to go around > > the lowercase terms to avoid confusion. >=20 > Done >=20 > > > > - Section 5.3, third paragraph: the text is written around the format > > (a=3Dsendonly), but I will instead put the focus on the semantics. = For > > example, I would write: > > > > Since the SRC does not expect to receive media from the SRS, the > > SRC > > will typically set each media stream of the SDP offer to only send > > media, > > by qualifying them with the a=3Dsendonly attribute. Conversely, as = the > > SRS > > only receives RTP streams from SRCs, the SDP answer will normally set > > each media stream to only receive media, by setting them with the > > a=3Drecvonly attribute, according to the procedures of RFC 3264 > > [RFC3264]. >=20 >=20 > Partly Done - The SDP answer part being set to a=3Drecvonly is not in the > current draft and could be added. >=20 >=20 > > > > - Section 5.3, fourth paragraph. As a matter of personal taste, I > > prefer > > that actions are attributed to either the SRC or the SRS, but not to > > the > > "SDP" (which is not an entity). For example, the sentence "the SDP must > > provide a label..." should be restated in terms of the "the SRC MUST > > include a label *attribute* (a=3Dlabel) in each media stream of the > > SDP"... >=20 > Done >=20 >=20 > > > > Also, in this fourth paragraph in Section 5.3, avoid the future tense, > > unless you really want to describe an action that will take a later > > time: > > "... will be used ..." >=20 > Done >=20 >=20 > > > > - Figure 4 in Section 5.3: the "o=3D" line is incorrect, due to sess-id > > and > > sess-version are set to 0. Also, the selected IP address is not being > > according to RFC 5737. Use this one instead: > > > > > > o=3DSRS 2890844526 2890844526 IN IP4 198.51.100.1 >=20 > Done >=20 > > > > - Figure 4 in Section 5.3: the "s=3D" line is incorrect according to RFC > > 3264. Use an white space or dash character instead: > > > > s=3D- >=20 > Done > > > > - Figure 4 in Section 5.3: the "c=3D" line is incorrect due to the = IP > > address not being according to RFC 5737. Use this one instead (should > > be > > the same IP address as in the o=3D line). > > > > c=3DIN IP4 198.51.100.1 >=20 > Done >=20 > > > > - Figure 4 in Section 5.3: all the m=3D lines are incorrect. All the > > lines > > should indicate an even port number for RTP, implicitly indicating that > > the consecutive port number is used for RTCP. Additionally, two lines > > referring to the H264 codec indicate that the stream is of type > > "audio", > > which is incorrect. Use the following "m=3D" lines (in order). > > > > m=3Daudio 12240 RTP/AVP 0 4 8 > > m=3Dvideo 22456 RTP/AVP 98 > > m=3Daudio 12242 RTP/AVP 0 4 8 > > m=3Dvideo 22458 RTP/AVP 98 >=20 > The 4th m-line still incorrectly indicates it is audio - Needs to be fixed. >=20 > > > > - Figure 4 in Section 5.3. Use a correct a=3Dfmtp line, for example: > > > > a=3Dfmtp:98 profile-level-id=3D42A01E; > > sprop-parameter-sets=3DZ0IACpZTBYmI,aMljiA=3D=3D >=20 > Done. >=20 >=20 > > > > > > - Section 5.3, 5th and 6th paragraphs: The text should be stated in > > terms > > of SDP offer/answer (we are in Section 5.3, which is "SDP handling"), > > and > > a reference to RFC 3264 should be added. Therefore: > > > > To remove a recorded media stream from the recording session, the > > SRC > > sends a new SDP offer where the port of the media stream to be > > removed is set to zero, according to the procedures in RFC 3264 > > [RFC3264]. > > > > To add a new media stream to the recording session, the SRC sends a > > new SDP offer adding a new media stream description in an m=3D line, > > according to the procedures in RFC 3264 [RFC3264]. >=20 > Done >=20 > > > > - Section 5.3, 7th paragraph should also be drafted in terms of SDP > > O/A. > > > > - Figure 6 in Section 5.4, use this SDP instead: > > > > v=3D0 > > o=3DSRS 2890844526 2890844526 IN IP4 198.51.100.1 > > s=3D- > > c=3DIN IP4 198.51.100.1 > > t=3D0 0 > > m=3Daudio 12240 RTP/AVP 0 4 8 > > a=3Dsendonly > > a=3Dlabel:1 > > >=20 > Done - The SDP example has been removed. >=20 >=20 > > - Section 6.2.1. The syntax is not correct. You should start by > > extending > > the "attribute" production in SDP, for example: > > > > attribute /=3D record-attr > > ; attribute defined in RFC 4566 > > record-attr =3D "record:" indication > > indication =3D "on" / "off" / "paused" >=20 > Done - now section 10.2.1 - But also applies to the recordpref-attr in what is > now 10.1.1 so this needs to be fixed. >=20 > > > > - Section 6.2.2. For discussion... Do you really need two attributes, > > "record" and "recordpref"? I believe both could be integrated into a > > single attribute. For example, you could have the a=3Drecord = attribute > > with > > the two values, one for the current status, and one of the current > > preference. > > >=20 > Done - Clarified on mailing list that we do need both. >=20 > > - Section 7.1. Although this is not related to SDP, in this paragraph > > you > > need to specify the registry where you want to register the new option > > tags. I believe it is the Session Initiation Protocol Parameters > > registry. > > > > - Section 7.5.1 and 7.5.2. The registration lacks contact name, email > > address, and telephone number, according to the requirements in RFC > > 4566. > > >=20 > Contact names and e-mail address is now included. RFC 4566 requires a > telephone number but personally I think this is not desirable due to privacy > issues. >=20 > > > > /Miguel > > -- > > Miguel A. Garcia > > +34-91-339-3608 > > Ericsson Spain From pravindran@sonusnet.com Thu May 31 12:16:54 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 72B0121F8609 for ; Thu, 31 May 2012 12:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.419 X-Spam-Level: X-Spam-Status: No, score=-6.419 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q76NwVbhNG9l for ; Thu, 31 May 2012 12:16:52 -0700 (PDT) Received: from na3sys010aog104.obsmtp.com (na3sys010aog104.obsmtp.com [74.125.245.76]) by ietfa.amsl.com (Postfix) with ESMTP id EA7DF21F8606 for ; Thu, 31 May 2012 12:16:51 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob104.postini.com ([74.125.244.12]) with SMTP ID DSNKT8fDo6XAFf1FlF8VgUVyyqE9M6QDa6c5@postini.com; Thu, 31 May 2012 12:16:52 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 31 May 2012 15:17:16 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Fri, 1 Jun 2012 00:46:45 +0530 From: "Ravindran, Parthasarathi" To: Leon Portman , "siprec@ietf.org" Thread-Topic: [siprec] Updated architecture draft after WGLC comments Thread-Index: Ac0+XcX0y87/u0ClSeq56ayEc5dcxgBARyZw Date: Thu, 31 May 2012 19:16:44 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C160396EE@inba-mail01.sonusnet.com> References: <07465C1D981ABC41A344374066AE1A2C3A7AEB818B@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C3A7AEB818B@TLVMBX01.nice.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: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C160396EEinbamail01sonus_" MIME-Version: 1.0 Subject: Re: [siprec] Updated architecture draft after WGLC comments 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, 31 May 2012 19:16:54 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C160396EEinbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Leon, I'm not very clear about the following text in Sec 3.2.2 " o Identify the session that is to be recorded. The actual mechanism of the identification depends on SRC policy." I agree with you in case of SIP UA acts as SRC, the local policy will serve= the purpose. In case of SIP B2BUA (SBC/IP PBX) acts as SRC, the local poli= cy may not be sufficient as some indication required to which session has t= o be indicated by SRS as the number of recording session or number of CS wi= thin the single RS will vary drastically from 1 session to 1000+ session at= a given time. The issue based on local policy over protocol mechanism is t= hat (B2BUA+) SRC MUST depend on proprietary session-id from SRS in the act= ual deployment. I'm writing the following solution to explain the issue in the above text. = As per http://www.ietf.org/mail-archive/web/siprec/current/msg03198.html t= hread, I understand that session-id may not be generic enough solution as i= t is not applicable to persistent usecase wherein session-id does not exist= when RS is established. So, I thought of proposing a solution based on new= header namely "recording-join" header which shall have Information about: 1) Communication session-id 2) Participant id 3) Communication session group id 4) Stream id ??? 5) Dialog (Normal Join) The header format shall be "Recording-join: id; type=3DCS/Participant/CSG/s= tream/dialog". Please let me know your opinion on this approach. Thanks Partha From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Leon Portman Sent: Wednesday, May 30, 2012 6:09 PM To: siprec@ietf.org Subject: [siprec] Updated architecture draft after WGLC comments Hello I just published updated draft after WGLC comments. Main changes: 1. Ram's comments: aligning definitions and terms with requirements a= nd metadata drafts, figures fixing, references updates 2. Charles comments: a. Fixing B2BUA honoring statements (also was comment from Ram). Nex= t text: The B2BUA/SRC is responsible for complying with requests from recording awa= re UAs or through some configured policies indicating that the communicatio= n session should not be recorded. b. Terms fixing and spelling mistakes c. Rephrasing in section 3.1.4, 3.2, 32.2., 3.2.5. d. IANA reference to the protocol draft e. Updates in the security section 3. IETF 83 meeting minutes Leon --_000_387F9047F55E8C42850AD6B3A7A03C6C160396EEinbamail01sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Leon,

 

I’m not very cle= ar about the following text in Sec 3.2.2

 

“   o  Identify the session that is to be reco= rded.  The actual mechanism

     = ; of the identification depends on SRC policy.”

 

I agree with you in case of SIP UA acts as SRC, the local policy wil= l serve the purpose. In case of SIP B2BUA (SBC/IP PBX) acts as SRC, the loc= al policy may not be sufficient as some indication required to which session has to be indicated by SRS as the num= ber of recording session or number of CS within the single RS will vary dra= stically from 1 session to 1000+ session at a given time. The issue bas= ed on local policy over protocol mechanism is that (B2BUA+) SRC  MUST depend on proprietary session-id from = SRS in the actual deployment.

 

I’m writing the following solution to explain the issue in the= above text.  As per http://www.ietf.org/mail-archive/web/siprec/current/msg03198.html th= read, I understand that session-id may not be generic enough solution as it= is not applicable to persistent usecase wherein session-id does not exist when RS is established. So, I thought of= proposing a solution based on new header namely “recording-join̶= 1; header which shall have

Information about:

 

1) &nbs= p;    Communication = session-id

2) &nbs= p;    Participant id=

3) &nbs= p;    Communication = session group id

4) &nbs= p;    Stream id ???<= o:p>

5) &nbs= p;    Dialog (Normal= Join)

 

The header format shall be “Recording-join: id; type=3DCS/Participant/CSG/stream/dialog”.

 

Please let me know your opinion on this approach.<= /p>

 

Thanks

Partha

 

 

From: siprec-b= ounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman
Sent: Wednesday, May 30, 2012 6:09 PM
To: siprec@ietf.org
Subject: [siprec] Updated architecture draft after WGLC comments

 

Hello

 

I just published updated draft after WGLC comments.<= o:p>

 

Main changes:

 

1.     &= nbsp; Ram's comments: aligning definitions and terms with= requirements and metadata drafts, figures fixing, references updates<= /o:p>

2.     &= nbsp; Charles comments:

a.       Fixing  B2BUA honoring statements (also was co= mment from Ram). Next text:

The B2BUA/SRC is responsible for complying with requ= ests from recording aware UAs or through some configured policies indicatin= g that the communication session should not be recorded.

b.      Terms fixing and spelling mistakes

c.       Rephrasing in section 3.1.4, 3.2, 32.2., 3.2.5.

d.      IANA reference to the protocol draft

e.      Updates in the security section

3.     &= nbsp; IETF 83 meeting minutes

Leon

 

--_000_387F9047F55E8C42850AD6B3A7A03C6C160396EEinbamail01sonus_-- From pkyzivat@alum.mit.edu Thu May 31 12:44:36 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 A614F21F8754 for ; Thu, 31 May 2012 12:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, J_CHICKENPOX_14=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 BTtovYS7uCh9 for ; Thu, 31 May 2012 12:44:36 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id E8ED121F8755 for ; Thu, 31 May 2012 12:44:35 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta01.westchester.pa.mail.comcast.net with comcast id Ghfa1j0031swQuc51jkbog; Thu, 31 May 2012 19:44:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta15.westchester.pa.mail.comcast.net with comcast id Gjkb1j00D07duvL3bjkbsw; Thu, 31 May 2012 19:44:35 +0000 Message-ID: <4FC7CA21.5020504@alum.mit.edu> Date: Thu, 31 May 2012 15:44:33 -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: <07465C1D981ABC41A344374066AE1A2C3A7AEB818B@TLVMBX01.nice.com> <387F9047F55E8C42850AD6B3A7A03C6C160396EE@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C160396EE@inba-mail01.sonusnet.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [siprec] Updated architecture draft after WGLC comments 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, 31 May 2012 19:44:36 -0000 I thought the definition of a mechanism for the SRS to indicate what to record to an SRC had been declared out of scope for our current effort. Thanks, Paul On 5/31/12 3:16 PM, Ravindran, Parthasarathi wrote: > Hi Leon, > > I’m not very clear about the following text in Sec 3.2.2 > > “o Identify the session that is to be recorded. The actual mechanism > > of the identification depends on SRC policy.” > > I agree with you in case of SIP UA acts as SRC, the local policy will > serve the purpose. In case of SIP B2BUA (SBC/IP PBX) acts as SRC, the > local policy may not be sufficient as some indication required to which > session has to be indicated by SRS as the number of recording session or > number of CS within the single RS will vary drastically from 1 session > to 1000+ session at a given time. The issue based on local policy over > protocol mechanism is that (B2BUA+) SRC MUST depend on proprietary > session-id from SRS in the actual deployment. > > I’m writing the following solution to explain the issue in the above > text. As per > http://www.ietf.org/mail-archive/web/siprec/current/msg03198.html > thread, I understand that session-id may not be generic enough solution > as it is not applicable to persistent usecase wherein session-id does > not exist when RS is established. So, I thought of proposing a solution > based on new header namely “recording-join” header which shall have > > Information about: > > 1)Communication session-id > > 2)Participant id > > 3)Communication session group id > > 4)Stream id ??? > > 5)Dialog (Normal Join) > > The header format shall be“Recording-join: id; > type=CS/Participant/CSG/stream/dialog”. > > Please let me know your opinion on this approach. > > Thanks > > Partha > > *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On > Behalf Of *Leon Portman > *Sent:* Wednesday, May 30, 2012 6:09 PM > *To:* siprec@ietf.org > *Subject:* [siprec] Updated architecture draft after WGLC comments > > Hello > > I just published updated draft after WGLC comments. > > Main changes: > > 1.Ram's comments: aligning definitions and terms with requirements and > metadata drafts, figures fixing, references updates > > 2.Charles comments: > > a.Fixing B2BUA honoring statements (also was comment from Ram). Next text: > > The B2BUA/SRC is responsible for complying with requests from recording > aware UAs or through some configured policies indicating that the > communication session should not be recorded. > > b.Terms fixing and spelling mistakes > > c.Rephrasing in section 3.1.4, 3.2, 32.2., 3.2.5. > > d.IANA reference to the protocol draft > > e.Updates in the security section > > 3.IETF 83 meeting minutes > > Leon > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pravindran@sonusnet.com Thu May 31 19:17:29 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1384A11E8072 for ; Thu, 31 May 2012 19:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_14=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 p5l4BWgY7E0L for ; Thu, 31 May 2012 19:17:28 -0700 (PDT) Received: from na3sys010aog114.obsmtp.com (na3sys010aog114.obsmtp.com [74.125.245.96]) by ietfa.amsl.com (Postfix) with ESMTP id 90E1121F84D6 for ; Thu, 31 May 2012 19:17:27 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob114.postini.com ([74.125.244.12]) with SMTP ID DSNKT8gmNxIUSzXHr+sc2BffwDs9uiyFEZkW@postini.com; Thu, 31 May 2012 19:17:27 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; Thu, 31 May 2012 22:17:52 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Fri, 1 Jun 2012 07:47:21 +0530 From: "Ravindran, Parthasarathi" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] Updated architecture draft after WGLC comments Thread-Index: AQHNP2XSW3sFybvA3ECdu9s0SGzJuJbktBOQ Date: Fri, 1 Jun 2012 02:17:20 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C1603977A@inba-mail01.sonusnet.com> References: <07465C1D981ABC41A344374066AE1A2C3A7AEB818B@TLVMBX01.nice.com> <387F9047F55E8C42850AD6B3A7A03C6C160396EE@inba-mail01.sonusnet.com> <4FC7CA21.5020504@alum.mit.edu> In-Reply-To: <4FC7CA21.5020504@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Updated architecture draft after WGLC comments 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, 01 Jun 2012 02:17:29 -0000 Paul, Sorry in case I'm reopening the discussion as the current proposed=20 mechanism proposes for the usage of proprietary vendor specific id=20 in the B2BUA+SRC deployment.=20 Some of the deployment uses SBC (B2BUA) as SRC, IP PBX=20 provides vendor specific CS id to SBC as well as to SRS and SRS=20 request for selective CS to be recorded using SRS initiated=20 recording mechanism. The point to be noted is that SBC has number=20 of CS simultaneously and not all the sessions are requested by SRS=20 to record (Selective recording). Here, SRC configuration (local policy) will not serve the purpose.=20 Of course, this issue is not applicable for SRC initiated sessions=20 as SRS shall reject selectively when RS INVITE is received. Thanks Partha=20 >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Paul Kyzivat >Sent: Friday, June 01, 2012 1:15 AM >To: siprec@ietf.org >Subject: Re: [siprec] Updated architecture draft after WGLC comments > >I thought the definition of a mechanism for the SRS to indicate what to >record to an SRC had been declared out of scope for our current effort. > > Thanks, > Paul > >On 5/31/12 3:16 PM, Ravindran, Parthasarathi wrote: >> Hi Leon, >> >> I'm not very clear about the following text in Sec 3.2.2 >> >> "o Identify the session that is to be recorded. The actual mechanism >> >> of the identification depends on SRC policy." >> >> I agree with you in case of SIP UA acts as SRC, the local policy will >> serve the purpose. In case of SIP B2BUA (SBC/IP PBX) acts as SRC, the >> local policy may not be sufficient as some indication required to >> which session has to be indicated by SRS as the number of recording >> session or number of CS within the single RS will vary drastically >> from 1 session to 1000+ session at a given time. The issue based on >> local policy over protocol mechanism is that (B2BUA+) SRC MUST depend >> on proprietary session-id from SRS in the actual deployment. >> >> I'm writing the following solution to explain the issue in the above >> text. As per >> http://www.ietf.org/mail-archive/web/siprec/current/msg03198.html >> thread, I understand that session-id may not be generic enough >> solution as it is not applicable to persistent usecase wherein >> session-id does not exist when RS is established. So, I thought of >> proposing a solution based on new header namely "recording-join" >> header which shall have >> >> Information about: >> >> 1)Communication session-id >> >> 2)Participant id >> >> 3)Communication session group id >> >> 4)Stream id ??? >> >> 5)Dialog (Normal Join) >> >> The header format shall be"Recording-join: id; >> type=3DCS/Participant/CSG/stream/dialog". >> >> Please let me know your opinion on this approach. >> >> Thanks >> >> Partha >> >> *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On >> Behalf Of *Leon Portman >> *Sent:* Wednesday, May 30, 2012 6:09 PM >> *To:* siprec@ietf.org >> *Subject:* [siprec] Updated architecture draft after WGLC comments >> >> Hello >> >> I just published updated draft after WGLC comments. >> >> Main changes: >> >> 1.Ram's comments: aligning definitions and terms with requirements and >> metadata drafts, figures fixing, references updates >> >> 2.Charles comments: >> >> a.Fixing B2BUA honoring statements (also was comment from Ram). Next >text: >> >> The B2BUA/SRC is responsible for complying with requests from >> recording aware UAs or through some configured policies indicating >> that the communication session should not be recorded. >> >> b.Terms fixing and spelling mistakes >> >> c.Rephrasing in section 3.1.4, 3.2, 32.2., 3.2.5. >> >> d.IANA reference to the protocol draft >> >> e.Updates in the security section >> >> 3.IETF 83 meeting minutes >> >> Leon >> >> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec