From john.elwell@siemens-enterprise.com Tue Aug 2 02:40:37 2011 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 5004F21F8F12 for ; Tue, 2 Aug 2011 02:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.479 X-Spam-Level: X-Spam-Status: No, score=-103.479 tagged_above=-999 required=5 tests=[AWL=-0.880, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUguYrAOsG5F for ; Tue, 2 Aug 2011 02:40:36 -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 D7DB921F8F07 for ; Tue, 2 Aug 2011 02:40:35 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 7C33E23F0593 for ; Tue, 2 Aug 2011 11:40:41 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 2 Aug 2011 11:40:41 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Tue, 2 Aug 2011 11:40:39 +0200 Thread-Topic: Doodle poll for SIPREC face-to-face September - urgent Thread-Index: AcxQ+D1Dcloxe0/zS7ug2lXmyz0a0g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Doodle poll for SIPREC face-to-face September - urgent 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, 02 Aug 2011 09:40:37 -0000 Please respond to this Doodle poll urgently: http://doodle.com/gpkg68pmyc7fwmzn At last week's meeting, we suggested an interim meeting in September and so= me folks were interested in a face-to-face. =20 - I suggest we find 2 consecutive days, and finish at lunch time on the sec= ond day. - Personally I can only make week beginning 5th or week beginning 19th (and= neither is certain). - Boston has been suggested, hosted by Acme Packet. I also explored London,= but I understand we would lack metadata experts. Since face-to-face meetings have to be announced 1 month in advance, please= respond by 4th August (we can keep the poll open a little longer for the l= atter week). We will not proceed with a face-to-face unless I get a sufficient number of= definites in time. I will send out a separate poll for a virtual interim in September. Thanks, John John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. From john.elwell@siemens-enterprise.com Tue Aug 2 02:41:02 2011 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 7A3D121F8F07 for ; Tue, 2 Aug 2011 02:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.469 X-Spam-Level: X-Spam-Status: No, score=-103.469 tagged_above=-999 required=5 tests=[AWL=-0.870, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGbZBzb5twks for ; Tue, 2 Aug 2011 02:41:01 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 6794A21F8F13 for ; Tue, 2 Aug 2011 02:41:01 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 7BB0023F0593 for ; Tue, 2 Aug 2011 11:41:09 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 2 Aug 2011 11:41:09 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Tue, 2 Aug 2011 11:41:07 +0200 Thread-Topic: Doodle poll for SIPREC virtual interim Thread-Index: AcxQ+E2zvzvdwfbSSFS9KUK/cR9ePw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Doodle poll for SIPREC virtual interim 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, 02 Aug 2011 09:41:02 -0000 Please respond to this poll by 2011-08-09: http://doodle.com/tdakgw5m5yxcx2pr This is for a virtual interim, if we fail to organize a face-to-face (see p= revious poll). I am looking for a two hour slot on each of two consecutive days, i.e., 5/6= , 8/9, 19/20 or 22/23 September. I will favour later times on the days conc= erned, since we had a rather early slot last time. John John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. = From magnus.westerlund@ericsson.com Tue Aug 2 08:55:36 2011 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 0C2D611E8084 for ; Tue, 2 Aug 2011 08:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.5 X-Spam-Level: X-Spam-Status: No, score=-106.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiwdQPjDN7AU for ; Tue, 2 Aug 2011 08:55:35 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id BF8E011E8080 for ; Tue, 2 Aug 2011 08:55:34 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-bc-4e381dfd03a5 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D6.4B.09774.DFD183E4; Tue, 2 Aug 2011 17:55:41 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Tue, 2 Aug 2011 17:55:41 +0200 Message-ID: <4E381DF6.8060203@ericsson.com> Date: Tue, 2 Aug 2011 17:55:34 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <4E2AFC1A.4090704@ericsson.com><4e2c02a0.c323440a.0d0e.ffffac0a@mx.google.com> <4E315D4B.8040104@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "siprec@ietf.org" Subject: Re: [siprec] [AVTCORE] Request to review a SIPREC draft related toRTP 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, 02 Aug 2011 15:55:36 -0000 Hi, Some reply. I will be unable to follow up on any additional comments for a while as I will be away on vacation. On 2011-07-28 18:26, Charles Eckel (eckelcu) wrote: > Hi Magnus, > > Thank you for reviewing and for your comments. Please see inline. > > >> -----Original Message----- From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf Of Magnus Westerlund >> Sent: Thursday, July 28, 2011 9:00 AM To: Roni Even Cc: >> siprec@ietf.org Subject: Re: [siprec] [AVTCORE] Request to review a >> SIPREC draft related toRTP >> >> Hi, >> >> Here are my review comments: >> >> In general the document is pretty straight forward and >> understandable. And make for me reasonable recommendations. As can >> be seen by the comments I think Section 4 is where the most >> improvements can be made. >> >> >> 1. In Section 4.1: The following sentence exist: More >> specifically, the SRC cannot multiple RTP streams with different >> SSRCs into a single RTP stream multiplexed by SSRC and/or CSRC. >> >> If I guess that there should be "put multiple RTP streams" I would >> really wonder over the "cannot". If the Streams are from the same >> call/multimedia session and from the corresponding RTP session >> between the UAs being recorded, I don't see why you couldn't put >> all the streams into the same RTP session. They are related, from >> the same context, and should also have unique SSRCs thus allowing >> the recording "translator" to create copies and forward them to the >> SRS. As long as each original stream has its own SSRC (assuming >> that the actual media isn't mixed in the SRC). > > I am not sure what I was trying to say here. Fixing the grammar is > easy, but as you point out, doing so results in a false statement. I > think it is best to remove this sentence completely. Yes, until you know what you want to say. > >> >> 2. Section 4.1: RTCP Receiver Reports generated by the SRS need to >> be forwarded to the relevant UA. >> >> If the goal is that the UAs shall know of the SRS then this is the >> correct approach. If not, then the SRC can in fact suppress the >> SRS's RTCP messages. > > Okay, but what would you suggest an SRC does it forwards packets from > UA1 to SRS and UA2, and reports from the SRS indicates loss of > packets while reports from a UA-B do not. I was trying to understand what requirements you really have. Yes having the SRC being a relaying RTP translator is simple and for adaptation and feedback to work it clearly need to forward the RTCP messages. After having thought about it I think you are right, that one of the defining things for using translator setup will be that RTCP for the SRS will be seen by the UAs. Even if doing media transcoding, the RTCP shall be forwarded, although in translated form. If you want another behavior you need to pick a different RTP behavior, either a mixer (Section 4.2) or separate the RTP session (Section 4.3). Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From john.elwell@siemens-enterprise.com Thu Aug 4 02:29:23 2011 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 2186D21F8B71 for ; Thu, 4 Aug 2011 02:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.46 X-Spam-Level: X-Spam-Status: No, score=-103.46 tagged_above=-999 required=5 tests=[AWL=-0.861, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCZLCUq5PBcO for ; Thu, 4 Aug 2011 02:29:22 -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 56C3921F8B6A for ; Thu, 4 Aug 2011 02:29:22 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 8E30423F053F; Thu, 4 Aug 2011 11:29:33 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 4 Aug 2011 11:29:33 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Thu, 4 Aug 2011 11:29:37 +0200 Thread-Topic: Draft minutes available Thread-Index: AcxSiQdnNkkKVJH9Qoiu6yIIPtjyqA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Draft minutes available 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, 04 Aug 2011 09:29:23 -0000 At: http://www.ietf.org/proceedings/81/minutes/siprec.txt Please let me have any corrections by 2011-08-14. John John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. From john.elwell@siemens-enterprise.com Thu Aug 4 02:31:40 2011 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 A12B021F8B73 for ; Thu, 4 Aug 2011 02:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.451 X-Spam-Level: X-Spam-Status: No, score=-103.451 tagged_above=-999 required=5 tests=[AWL=-0.852, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cn-VA6lT129Q for ; Thu, 4 Aug 2011 02:31:40 -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 0F62321F8B71 for ; Thu, 4 Aug 2011 02:31:40 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 8C19C1EB84DA for ; Thu, 4 Aug 2011 11:31:53 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 4 Aug 2011 11:31:53 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Thu, 4 Aug 2011 11:31:57 +0200 Thread-Topic: Consensus calls from Quebec Thread-Index: AcxSiVrjTGEpg3bpR0yZYzzWcpQl0A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Consensus calls from Quebec 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, 04 Aug 2011 09:31:40 -0000 The following were agreed at the Quebec face-to-face. Please raise any obje= ctions by 2011-08-14. Metadata: - Include associate/dissociate times for Participant in a CS. - A Participant can exist outside the context of a CS or CSG. - Contact header field parameters to be included as an attribute of an asso= ciation between Participant and CS. - Multiple identifiers to be allowed for a Participant. - Metadata to include information to associate a Participant with a CSRC va= lue. - All receiving Participants are to be explicitly indicated (no receive by = default). Protocol: - Proceed with snapshot request to recover from synchronization issues (but= not syntax errors). - Inclusion of sequence number in metadata XML. - A snapshot request to lead to repeat of SDP (offer-answer) in addition to= re-sending of XML. - Addition of option tag(s) so that they can be used in Require to ensure R= S failure if non-compliant UA encountered. - Adoption of draft as WG item (note that it will not at this stage include= RTP text - that will be adopted later). John John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. = From john.elwell@siemens-enterprise.com Thu Aug 4 02:32:37 2011 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 6E8AC21F86BE for ; Thu, 4 Aug 2011 02:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.442 X-Spam-Level: X-Spam-Status: No, score=-103.442 tagged_above=-999 required=5 tests=[AWL=-0.843, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6XjOQd2-M64 for ; Thu, 4 Aug 2011 02:32:36 -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 B708421F861E for ; Thu, 4 Aug 2011 02:32:36 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 945A523F05EE for ; Thu, 4 Aug 2011 11:32:50 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 4 Aug 2011 11:32:50 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Thu, 4 Aug 2011 11:32:54 +0200 Thread-Topic: Matters needing further discussion Thread-Index: AcxSiXzNzCe5eD/kRuaYeIP3c5L3dA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Matters needing further discussion 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, 04 Aug 2011 09:32:37 -0000 The following issues discussed in Quebec need further list discussion. Metadata: - How to model and format associations between Participants and CSs, includ= ing times, and likewise between Media Streams and Participants. - How to format Contact header field parameters in XML. - How to deal with a Participant identifier marked as private. - Whether to identify the source of a Participant identifier (From or PAI). - Format of unique identifiers (text needed, probably based on option 3 pro= posed by Paul). Protocol: - Initiation of RS from SRS to SRC (John/Andy to provide a more concrete pr= oposal). RTP: - I think this probably first needs a revision from Charles. John John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. From pkyzivat@alum.mit.edu Thu Aug 4 07:25:16 2011 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 46B3C21F8565 for ; Thu, 4 Aug 2011 07:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rC7JYY-XUmAE for ; Thu, 4 Aug 2011 07:25:15 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id A89C121F8549 for ; Thu, 4 Aug 2011 07:25:15 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by QMTA11.westchester.pa.mail.comcast.net with comcast id GERC1h00E1ap0As5BERXVL; Thu, 04 Aug 2011 14:25:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta22.westchester.pa.mail.comcast.net with comcast id GERL1h00d0tdiYw3iERRF8; Thu, 04 Aug 2011 14:25:30 +0000 Message-ID: <4E3AABCD.4010603@alum.mit.edu> Date: Thu, 04 Aug 2011 10:25:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: siprec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] associate a Participant with a CSRC value 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, 04 Aug 2011 14:25:16 -0000 On 8/4/11 5:31 AM, Elwell, John wrote: > The following were agreed at the Quebec face-to-face. Please raise any objections by 2011-08-14. > - Metadata to include information to associate a Participant with a CSRC value. I'd like to double check with those who know RTP better than I: I *presume* that CSRC assignments may be made on a per-media stream basis, and so the association of Participant to CSRC must be specified separately for each stream. So, a participant may have multiple CSRCs - potentially a different one for each stream in which it participates. And IIUC the CSRC value representing a participant can change over time within a stream. I think it may also be the case that one CSRC value may represent different participants in different streams, though its my impression this would be rare. Does anyone disagree with the above? And a question: can a single participant have multiple CSRCs concurrently for the same stream? Thanks, Paul From pkyzivat@alum.mit.edu Thu Aug 4 08:01:52 2011 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 05D9921F8B5A for ; Thu, 4 Aug 2011 08:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKoFAlukz0wM for ; Thu, 4 Aug 2011 08:01:51 -0700 (PDT) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by ietfa.amsl.com (Postfix) with ESMTP id 88FB621F8B1D for ; Thu, 4 Aug 2011 08:01:51 -0700 (PDT) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta15.emeryville.ca.mail.comcast.net with comcast id GEfo1h0091ZMdJ4AFF23yH; Thu, 04 Aug 2011 15:02:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta16.emeryville.ca.mail.comcast.net with comcast id GEzf1h00s0tdiYw8cEzg08; Thu, 04 Aug 2011 14:59:41 +0000 Message-ID: <4E3AB469.5090507@alum.mit.edu> Date: Thu, 04 Aug 2011 11:02:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: siprec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Whether to identify the source of a Participant identifier 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, 04 Aug 2011 15:01:52 -0000 On 8/4/11 5:32 AM, Elwell, John wrote: > The following issues discussed in Quebec need further list discussion. > - Whether to identify the source of a Participant identifier (From or PAI). I want to hear from others on whether this is important or not. My default assumption is that we ought to provide a way to specify this. But I think we can still make it optional, for an SRC that doesn't want to provide it, as well as for participants whose identity is learned in some other way than via a sip header. If so, then the question is: HOW? I see a couple of approaches for use in xml: - an explicit enumeration type covering all the known headers that could be the source - a simple string element or attribute that is to contain the string form of the header name from which the value was obtained. I'm reluctant to go with the enumeration, because it isn't conveniently extensible. So, while I am not especially fond of including the actual header name string, I'm inclined to propose that we do so as the lesser of evils. Thanks, Paul From Henry.Lum@alcatel-lucent.com Thu Aug 4 08:06:35 2011 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 AE8C621F8B71 for ; Thu, 4 Aug 2011 08:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQomSFZCVbaR for ; Thu, 4 Aug 2011 08:06:35 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 05DE421F8B25 for ; Thu, 4 Aug 2011 08:06:34 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p74F6lBq008697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Aug 2011 10:06:47 -0500 (CDT) Received: from relay-out2.dc (relay-out2.dc.genesyslab.com [172.22.68.188]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p74F6jBc011247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Aug 2011 10:06:47 -0500 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc (8.13.8+Sun/8.13.8) with ESMTP id p74F6jRm014660; Thu, 4 Aug 2011 08:06:45 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Aug 2011 08:06:44 -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, 4 Aug 2011 08:06:42 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF740766E39F@NAHALD.us.int.genesyslab.com> In-Reply-To: <4E33572D.7030107@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Reasons for snapshot request Thread-Index: AcxOU90+F7AfPisAStOA6pJ0EUJkvQEXfuow References: <61FF1DCB-03BC-4C9C-9D2B-CE7C6F7DFA75@acmepacket.com><059AF07365DC474393A19A3AF187DF7401A5BDA3@NAHALD.us.int.genesyslab.com><38929269-1311874874-cardhu_decombobulator_blackberry.rim.net-959204456-@b26.c3.bise3.blackberry><35BCE99A477D6A4986FB2216D8CF2CFD07272AE2@XMB-BGL-417.cisco.com> <4E33572D.7030107@alum.mit.edu> From: "Henry Lum" To: "Paul Kyzivat" , X-OriginalArrivalTime: 04 Aug 2011 15:06:44.0926 (UTC) FILETIME=[1FE1E5E0:01CC52B8] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [siprec] Reasons for snapshot request 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, 04 Aug 2011 15:06:35 -0000 I think we have already discussed this before that the SIP response is processed before the application layer so it would be "too late" for an SRS to send a SIP error response to indicate issues with the metadata in this message. What I was initially thinking of is that if the SRS is in a troubled state it could generate a SIP error response regardless of what the application content is, however, as others have pointed out this is problematic since it would take a long time before the SRC generate another update.=20 Speaking of the content of the snapshot body, some has suggested to govern response codes instead of free-form text so that we don't have to deal with internationalization. What kind of response code can we come up with for an SRS? So far we have identified two failure scenarios that an SRS can issue a snapshot request for (with the proposed codes): - 500 SRS Internal Error - 510 Missing Metadata Sequence Number We have agreed that syntax and semantic errors do not belong to snapshot requests; do we have other failure scenarios to spell out? Regards, Henry -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Friday, July 29, 2011 8:58 PM To: siprec@ietf.org Subject: Re: [siprec] Reasons for snapshot request IMO we should not assume that the SRS processes the metadata before=20 responding to the message carrying it. (And I think we decided that long ago.) Hence I think it unreasonable to use an error response to the sip=20= message to indicate there are issues with the metadata. (Its also a=20 "layer violation".) And if we are not assuming that, then it seems unreasonable for the SRS=20= to have to wait for another request from the SRC before it can request a snapshot. So, I think the request for a snapshot should be handled as *some* sort=20= of data in a body of a message from SRS to SRC. I think it does not=20 matter whether that is carried in a request or a response. I'm less=20 concerned with the *form* of that body. Thanks, Paul On 7/29/11 5:46 PM, Charles Eckel (eckelcu) wrote: > An SRS could do either, but the former is how I would expect for the > mechanism to be used in general. If an SRS experiences some asynchronous > error or detects a mismatch independent of SIP re-INVITE/UPDATE, then > the latter case could apply. But I see that as being pretty unlikely and > would not want to complicate the protocol unnecessarily to accommodate > it. > > Cheers, > Charles > >> -----Original Message----- >> From: Ram Mohan R (rmohanr) >> Couple of questions: >> - Are we saying here that a SRS must send an error response (4XX) on > getting an error while processing >> an UPDATE/re-INVITE request having SIPREC XML body ? >> Or are we saying that an SRS in response to a UPDATE/re-INVITE asks > for complete snapshot through an >> error code even though the processing of UPDATE itself may not have > any errors ? >> >> I agree with Leon that this may not be efficient as an SRS has to wait > till it receives an UPDATE/re- >> INVITE from SRC before asking for a snapshot by when it may have > already lost a good amount of >> metadata. _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From pkyzivat@alum.mit.edu Thu Aug 4 09:21:44 2011 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 220AF21F89A1 for ; Thu, 4 Aug 2011 09:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S02GUd642gNA for ; Thu, 4 Aug 2011 09:21:43 -0700 (PDT) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEBE21F89C2 for ; Thu, 4 Aug 2011 09:21:43 -0700 (PDT) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta10.emeryville.ca.mail.comcast.net with comcast id GGCb1h00A1Y3wxoAAGMvgZ; Thu, 04 Aug 2011 16:21:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta15.emeryville.ca.mail.comcast.net with comcast id GGMf1h01f0tdiYw8bGMhZD; Thu, 04 Aug 2011 16:21:44 +0000 Message-ID: <4E3AC71D.4060701@alum.mit.edu> Date: Thu, 04 Aug 2011 12:21:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Henry Lum References: <61FF1DCB-03BC-4C9C-9D2B-CE7C6F7DFA75@acmepacket.com><059AF07365DC474393A19A3AF187DF7401A5BDA3@NAHALD.us.int.genesyslab.com><38929269-1311874874-cardhu_decombobulator_blackberry.rim.net-959204456-@b26.c3.bise3.blackberry><35BCE99A477D6A4986FB2216D8CF2CFD07272AE2@XMB-BGL-417.cisco.com> <4E33572D.7030107@alum.mit.edu> <059AF07365DC474393A19A3AF187DF740766E39F@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF740766E39F@NAHALD.us.int.genesyslab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] Reasons for snapshot request 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, 04 Aug 2011 16:21:44 -0000 On 8/4/11 11:06 AM, Henry Lum wrote: > I think we have already discussed this before that the SIP response is > processed before the application layer so it would be "too late" for an > SRS to send a SIP error response to indicate issues with the metadata in > this message. What I was initially thinking of is that if the SRS is in > a troubled state it could generate a SIP error response regardless of > what the application content is, however, as others have pointed out > this is problematic since it would take a long time before the SRC > generate another update. > > Speaking of the content of the snapshot body, some has suggested to > govern response codes instead of free-form text so that we don't have to > deal with internationalization. What kind of response code can we come > up with for an SRS? So far we have identified two failure scenarios that > an SRS can issue a snapshot request for (with the proposed codes): > > - 500 SRS Internal Error > - 510 Missing Metadata Sequence Number > > We have agreed that syntax and semantic errors do not belong to snapshot > requests; do we have other failure scenarios to spell out? There is another option: a text value that is not intended for display to an end user - but only for logging. As long as its presented that way I don't think we run into internationalization issues. And since the SRC will typically not be attached to a user directly, it probably wouldn't want to display it anyway. I don't think we really need codes, because there aren't really any distinct actions to be taken by the SRC. Always just the same action - to send a snapshot. IMO this is "good enough". Thanks, Paul > Regards, > Henry > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Friday, July 29, 2011 8:58 PM > To: siprec@ietf.org > Subject: Re: [siprec] Reasons for snapshot request > > IMO we should not assume that the SRS processes the metadata before > responding to the message carrying it. (And I think we decided that long > > ago.) Hence I think it unreasonable to use an error response to the sip > message to indicate there are issues with the metadata. (Its also a > "layer violation".) > > And if we are not assuming that, then it seems unreasonable for the SRS > to have to wait for another request from the SRC before it can request a > > snapshot. > > So, I think the request for a snapshot should be handled as *some* sort > of data in a body of a message from SRS to SRC. I think it does not > matter whether that is carried in a request or a response. I'm less > concerned with the *form* of that body. > > Thanks, > Paul > > On 7/29/11 5:46 PM, Charles Eckel (eckelcu) wrote: >> An SRS could do either, but the former is how I would expect for the >> mechanism to be used in general. If an SRS experiences some > asynchronous >> error or detects a mismatch independent of SIP re-INVITE/UPDATE, then >> the latter case could apply. But I see that as being pretty unlikely > and >> would not want to complicate the protocol unnecessarily to accommodate >> it. >> >> Cheers, >> Charles >> >>> -----Original Message----- >>> From: Ram Mohan R (rmohanr) > >>> Couple of questions: >>> - Are we saying here that a SRS must send an error response (4XX) on >> getting an error while processing >>> an UPDATE/re-INVITE request having SIPREC XML body ? >>> Or are we saying that an SRS in response to a UPDATE/re-INVITE asks >> for complete snapshot through an >>> error code even though the processing of UPDATE itself may not have >> any errors ? >>> >>> I agree with Leon that this may not be efficient as an SRS has to > wait >> till it receives an UPDATE/re- >>> INVITE from SRC before asking for a snapshot by when it may have >> already lost a good amount of >>> metadata. > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > > > ------------------------------------------------------------------------------------------------------------------- > CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities. > > From john.elwell@siemens-enterprise.com Thu Aug 4 23:33:38 2011 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 8794811E8096 for ; Thu, 4 Aug 2011 23:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.433 X-Spam-Level: X-Spam-Status: No, score=-103.433 tagged_above=-999 required=5 tests=[AWL=-0.834, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nbad9ALK8phg for ; Thu, 4 Aug 2011 23:33:37 -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 BA43811E8073 for ; Thu, 4 Aug 2011 23:33:37 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id EDF3B23F0408; Fri, 5 Aug 2011 08:33:50 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 5 Aug 2011 08:33:50 +0200 From: "Elwell, John" To: Meetecho IETF support , "siprec@ietf.org" Date: Fri, 5 Aug 2011 08:33:49 +0200 Thread-Topic: [siprec] SIPREC recording available Thread-Index: AcxNwCxcF587U/MDSqC8dbiL/NlqGwFeM8Zw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] SIPREC recording available 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, 05 Aug 2011 06:33:38 -0000 Meetecho folks, I used Meetecho to help supplement the raw notes when I was writing the min= utes, and I found it very useful. Just a couple of points: - Is it possible to enlarge the video window? - Sometimes slide changing was late, but clearly that is a manual process. It would be useful if presenters would put slide numbers on their slides. I put links to the separate recordings in the appropriate sections of the m= inutes. John > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Meetecho IETF support > Sent: 29 July 2011 08:22 > To: siprec@ietf.org > Subject: [siprec] SIPREC recording available >=20 > Dear all, >=20 > the full recording (synchronized video, audio, slides and=20 > jabber room)=20 > of yesterday's SIPREC session is available. >=20 > You can watch it by either clicking the proper link on the=20 > remote participation page=20 > (http://www.ietf.org/meeting/81/remote-participation.html#Meet > echo), or by directly accessing the following URL: > http://www.meetecho.com/ietf81/recordings >=20 > For the chair(s): please feel free to put the link to the=20 > recording in the minutes, if you think this might be useful. >=20 > In case of problems with the playout, just drop an e-mail to=20 > ietf-support@meetecho.com. >=20 > Cheers, > the Meetecho Team >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From john.elwell@siemens-enterprise.com Fri Aug 5 01:09:36 2011 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 183E621F8BB0 for ; Fri, 5 Aug 2011 01:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.424 X-Spam-Level: X-Spam-Status: No, score=-103.424 tagged_above=-999 required=5 tests=[AWL=-0.825, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91PgsrQmDT1m for ; Fri, 5 Aug 2011 01:09:31 -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 167C221F8BC4 for ; Fri, 5 Aug 2011 01:09:30 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 5671023F0518 for ; Fri, 5 Aug 2011 10:09:45 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 5 Aug 2011 10:09:45 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Fri, 5 Aug 2011 10:09:43 +0200 Thread-Topic: Doodle poll for SIPREC face-to-face September - urgent Thread-Index: AcxQ+D1Dcloxe0/zS7ug2lXmyz0a0gCTk4eQ Message-ID: Keywords: SIPREC 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] Doodle poll for SIPREC face-to-face September - urgent 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, 05 Aug 2011 08:09:36 -0000 The response to date is not encouraging - only 4 definites plus 3 possibles= . This rules out having a face-to-face meeting on week beginning 2011-09-05= , but I will keep the poll open a few more days to see if there is further = interest in a face-to-face week beginning 2011-09-19.=20 John > -----Original Message----- > From: Elwell, John=20 > Sent: 02 August 2011 10:41 > To: siprec@ietf.org > Subject: Doodle poll for SIPREC face-to-face September - urgent >=20 > Please respond to this Doodle poll urgently: > http://doodle.com/gpkg68pmyc7fwmzn >=20 > At last week's meeting, we suggested an interim meeting in=20 > September and some folks were interested in a face-to-face. =20 > - I suggest we find 2 consecutive days, and finish at lunch=20 > time on the second day. > - Personally I can only make week beginning 5th or week=20 > beginning 19th (and neither is certain). > - Boston has been suggested, hosted by Acme Packet. I also=20 > explored London, but I understand we would lack metadata experts. >=20 > Since face-to-face meetings have to be announced 1 month in=20 > advance, please respond by 4th August (we can keep the poll=20 > open a little longer for the latter week). >=20 > We will not proceed with a face-to-face unless I get a=20 > sufficient number of definites in time. >=20 > I will send out a separate poll for a virtual interim in September. >=20 > Thanks, >=20 > John >=20 >=20 > John Elwell > Tel: +44 1908 817801 (office and mobile) > Email: john.elwell@siemens-enterprise.com > http://www.siemens-enterprise.com/uk/ >=20 > Siemens Enterprise Communications Limited. > Registered office: Brickhill Street, Willen Lake, Milton=20 > Keynes, MK15 0DJ. > Registered No: 5903714, England. >=20 > Siemens Enterprise Communications Limited is a Trademark=20 > Licensee of Siemens AG. > = From john.elwell@siemens-enterprise.com Fri Aug 5 02:03:39 2011 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 A49AA21F8AD8 for ; Fri, 5 Aug 2011 02:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.416 X-Spam-Level: X-Spam-Status: No, score=-103.416 tagged_above=-999 required=5 tests=[AWL=-0.817, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEwNzipsXL5B for ; Fri, 5 Aug 2011 02:03:39 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1C44C21F8AE6 for ; Fri, 5 Aug 2011 02:03:38 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 108311EB84A2 for ; Fri, 5 Aug 2011 11:03:53 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 5 Aug 2011 11:03:53 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Fri, 5 Aug 2011 11:03:51 +0200 Thread-Topic: Do we need a stream element? Thread-Index: AcxTTpgbJ+rctZgoRi6Cw50KyIfKeQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Do we need a stream element? 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, 05 Aug 2011 09:03:39 -0000 (as individual) Do we need a stream element in the XML? In Quebec we said start and stop ti= mes should be tied to the association between participant and stream, not t= o the stream itself. This seems to suggest they be part of the send and rec= v sub-elements of a participant element. The mode element also seems not to= be needed, since mixed or separate can be deduced from other information. = The only relevant information seems to be the label. So it seems to be a waste of space for send and recv sub-elements of a part= icipant element to contain a unique ID pointing to a stream element that th= en just contains a label. Why don't the send and recv elements simply conta= in the label (plus start and stop times, to meet what was decided in Quebec= )? In other words, the MediaStream element in the model is entirely represente= d by a media description in SDP. For example, the schema might look something like this: John= From pkyzivat@alum.mit.edu Fri Aug 5 07:20:15 2011 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 D544221F8ABE for ; Fri, 5 Aug 2011 07:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M72YZrN4ew3u for ; Fri, 5 Aug 2011 07:20:15 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id E360621F8AFE for ; Fri, 5 Aug 2011 07:20:14 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta09.westchester.pa.mail.comcast.net with comcast id GeFp1h00D27AodY59eLZxV; Fri, 05 Aug 2011 14:20:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta19.westchester.pa.mail.comcast.net with comcast id GeLT1h02X0tdiYw3feLW1V; Fri, 05 Aug 2011 14:20:32 +0000 Message-ID: <4E3BFC29.6050001@alum.mit.edu> Date: Fri, 05 Aug 2011 10:20:25 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: siprec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Do we need a stream element? 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, 05 Aug 2011 14:20:15 -0000 John, On 8/5/11 5:03 AM, Elwell, John wrote: > (as individual) > > Do we need a stream element in the XML? In Quebec we said start and stop times should be tied to the association between participant and stream, not to the stream itself. This seems to suggest they be part of the send and recv sub-elements of a participant element. The mode element also seems not to be needed, since mixed or separate can be deduced from other information. The only relevant information seems to be the label. > > So it seems to be a waste of space for send and recv sub-elements of a participant element to contain a unique ID pointing to a stream element that then just contains a label. Why don't the send and recv elements simply contain the label (plus start and stop times, to meet what was decided in Quebec)? > > In other words, the MediaStream element in the model is entirely represented by a media description in SDP. I think your point here is that the stream "class" will still exist in the model, but its conveyed entirely in SDP and thus does not need an xml representation. One thing the xml element provides is a way to assign a true globally unique id, which allows the same stream to be referenced from multiple recording sessions. Until now, we have not stated that labels are unique ids. Rather, we have said (at least informally) that the labels are transient, used to bind the stream xml to the SDP within a single message. I suppose we *could* specify a UUID representation that can be used as a label in SDP. (That is possible, but would have to be an unusual radix64 representation, or we could use hex.) I'm a bit reluctant to go this way because it eliminates the opportunity to associate other data with a stream, including extension data. But lets discuss it further. Thanks, Paul > For example, the schema might look something like this: > > minOccurs="0" maxOccurs="unbounded"/> > minOccurs="0" maxOccurs="unbounded"/> > > > > minOccurs="0" maxOccurs="1"/> > minOccurs="0"/> > minOccurs="0"/> > minOccurs="0"/> > > > > John > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From pkyzivat@alum.mit.edu Fri Aug 5 08:58:10 2011 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 5A67921F8BCB for ; Fri, 5 Aug 2011 08:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWcb-KFDHm8x for ; Fri, 5 Aug 2011 08:58:09 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id C640B21F8B91 for ; Fri, 5 Aug 2011 08:58:09 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta04.westchester.pa.mail.comcast.net with comcast id GfwS1h00D1YDfWL54fyU95; Fri, 05 Aug 2011 15:58:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta20.westchester.pa.mail.comcast.net with comcast id Gfy81h02N0tdiYw3gfyMrW; Fri, 05 Aug 2011 15:58:26 +0000 Message-ID: <4E3C130F.30002@alum.mit.edu> Date: Fri, 05 Aug 2011 11:58:07 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "siprec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [siprec] f2f 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, 05 Aug 2011 15:58:10 -0000 John, I'm having technical problems with doodle that are preventing me from voting. I'm available for the f2f any of the listed times as long as it is in Boston. Thanks, Paul From john.elwell@siemens-enterprise.com Mon Aug 8 01:07:46 2011 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 C576821F8753 for ; Mon, 8 Aug 2011 01:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.408 X-Spam-Level: X-Spam-Status: No, score=-103.408 tagged_above=-999 required=5 tests=[AWL=-0.809, 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 bK0oBO6qwDG6 for ; Mon, 8 Aug 2011 01:07:46 -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 9AFF121F873D for ; Mon, 8 Aug 2011 01:07:45 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id F029E23F0558; Mon, 8 Aug 2011 10:08:06 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 8 Aug 2011 10:08:06 +0200 From: "Elwell, John" To: Paul Kyzivat , "siprec@ietf.org" Date: Mon, 8 Aug 2011 10:08:07 +0200 Thread-Topic: [siprec] Do we need a stream element? Thread-Index: AcxTet680wnZkrO8Rg+P5jnxQ3tFhACJlI9Q Message-ID: References: <4E3BFC29.6050001@alum.mit.edu> In-Reply-To: <4E3BFC29.6050001@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Do we need a stream element? 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, 08 Aug 2011 08:07:46 -0000 =20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 05 August 2011 15:20 > To: siprec@ietf.org > Subject: Re: [siprec] Do we need a stream element? >=20 > John, >=20 > On 8/5/11 5:03 AM, Elwell, John wrote: > > (as individual) > > > > Do we need a stream element in the XML? In Quebec we said=20 > start and stop times should be tied to the association=20 > between participant and stream, not to the stream itself.=20 > This seems to suggest they be part of the send and recv=20 > sub-elements of a participant element. The mode element also=20 > seems not to be needed, since mixed or separate can be=20 > deduced from other information. The only relevant information=20 > seems to be the label. > > > > So it seems to be a waste of space for send and recv=20 > sub-elements of a participant element to contain a unique ID=20 > pointing to a stream element that then just contains a label.=20 > Why don't the send and recv elements simply contain the label=20 > (plus start and stop times, to meet what was decided in Quebec)? > > > > In other words, the MediaStream element in the model is=20 > entirely represented by a media description in SDP. >=20 > I think your point here is that the stream "class" will still=20 > exist in=20 > the model, but its conveyed entirely in SDP and thus does not need an=20 > xml representation. >=20 > One thing the xml element provides is a way to assign a true globally=20 > unique id, which allows the same stream to be referenced from=20 > multiple=20 > recording sessions. Until now, we have not stated that labels=20 > are unique=20 > ids. Rather, we have said (at least informally) that the labels are=20 > transient, used to bind the stream xml to the SDP within a=20 > single message. [JRE] From past discussions, I am led to believe that a stream element repr= esents an RS stream, and therefore the idea of having a unique ID that work= s from different RSs doesn't seem relevant. >=20 > I suppose we *could* specify a UUID representation that can=20 > be used as a=20 > label in SDP. (That is possible, but would have to be an=20 > unusual radix64=20 > representation, or we could use hex.) >=20 > I'm a bit reluctant to go this way because it eliminates the=20 > opportunity=20 > to associate other data with a stream, including extension data. But=20 > lets discuss it further. [JRE] I see your point, but would such extension data be more appropriate a= s part of a send or recv element? John (as individual) John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. >=20 > Thanks, > Paul >=20 > > For example, the schema might look something like this: > > > > > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > > > > > > > > minOccurs=3D"0" maxOccurs=3D"1"/> > > > minOccurs=3D"0"/> > > > minOccurs=3D"0"/> > > > minOccurs=3D"0"/> > > > > > > > > John > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From pkyzivat@alum.mit.edu Mon Aug 8 11:33:59 2011 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 519DE21F8BA2 for ; Mon, 8 Aug 2011 11:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 AMztCG2hpzWS for ; Mon, 8 Aug 2011 11:33:58 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id 23D4D21F84E6 for ; Mon, 8 Aug 2011 11:33:57 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta04.westchester.pa.mail.comcast.net with comcast id HuAn1h0081YDfWL54uaRqr; Mon, 08 Aug 2011 18:34:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta20.westchester.pa.mail.comcast.net with comcast id HuaQ1h01b0tdiYw3guaQmh; Mon, 08 Aug 2011 18:34:25 +0000 Message-ID: <4E402C2F.1080103@alum.mit.edu> Date: Mon, 08 Aug 2011 14:34:23 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Elwell, John" References: <4E3BFC29.6050001@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Do we need a stream element? 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, 08 Aug 2011 18:33:59 -0000 On 8/8/11 4:08 AM, Elwell, John wrote: > > >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 05 August 2011 15:20 >> To: siprec@ietf.org >> Subject: Re: [siprec] Do we need a stream element? >> >> John, >> >> On 8/5/11 5:03 AM, Elwell, John wrote: >>> (as individual) >>> >>> Do we need a stream element in the XML? In Quebec we said >> start and stop times should be tied to the association >> between participant and stream, not to the stream itself. >> This seems to suggest they be part of the send and recv >> sub-elements of a participant element. The mode element also >> seems not to be needed, since mixed or separate can be >> deduced from other information. The only relevant information >> seems to be the label. >>> >>> So it seems to be a waste of space for send and recv >> sub-elements of a participant element to contain a unique ID >> pointing to a stream element that then just contains a label. >> Why don't the send and recv elements simply contain the label >> (plus start and stop times, to meet what was decided in Quebec)? >>> >>> In other words, the MediaStream element in the model is >> entirely represented by a media description in SDP. >> >> I think your point here is that the stream "class" will still >> exist in >> the model, but its conveyed entirely in SDP and thus does not need an >> xml representation. >> >> One thing the xml element provides is a way to assign a true globally >> unique id, which allows the same stream to be referenced from >> multiple >> recording sessions. Until now, we have not stated that labels >> are unique >> ids. Rather, we have said (at least informally) that the labels are >> transient, used to bind the stream xml to the SDP within a >> single message. > [JRE] From past discussions, I am led to believe that a stream element represents an RS stream, and therefore the idea of having a unique ID that works from different RSs doesn't seem relevant. I suspect maybe we are still not all on the same page about this. Lets consider the case of a UA that is its own SRC. I pick that case simply because it is then plausible that it knows a fair amount about the things it is recording. For instance, it might be an office phone, P, in an office that gets a lot of calls and wants to record them all. It could establish an RS at the beginning of the day, and use it for all calls in which it is involved. Assume P makes a voice call to A. Then after that completes, P gets a call from B, and that completes. If P does its own mixing, then it needs only a single m-line in the RS to accomplish this, using if first for the call with A and then for the call with B. The question is whether that is one MS object, or two. There will be two session elements, one for each call. Each will refer to one MS element - either the same one, or a different one. If its a single one, then for the duration of the first call the participants of the MS will be P and A, while during the 2nd call the participants will be P & B. Is that enough for the SRS to understand what is going on? It gets more complex of the two calls are overlapped in time. Perhaps the call from B comes before the call with A is over. So P puts A on hold, answers and completes the call with B and then resumes the call with A. In that case, if there is no MoH, P may still need only a single m-line in the RS to handle this. Then, the participants for the only MS are first P&A, then P&B, then P&A. The MS would then need to be switched from the first session, to the second, and back to the first. I think this *can* work either way, and is to some extent a matter of taste. But it has to be carefully documented one way or the other. In *my* mind having separate MS objects makes sense, but maybe that is just a bias on my part. Thanks, Paul >> I suppose we *could* specify a UUID representation that can >> be used as a >> label in SDP. (That is possible, but would have to be an >> unusual radix64 >> representation, or we could use hex.) >> >> I'm a bit reluctant to go this way because it eliminates the >> opportunity >> to associate other data with a stream, including extension data. But >> lets discuss it further. > [JRE] I see your point, but would such extension data be more appropriate as part of a send or recv element? I think either place could make sense, but for different things. If you have data about why the sending is taking place or what it is about, then that belongs on the element. If you have data on why the stream as a whole exists, regardless of sender, then extending the MS makes more sense. (But if the MS merely represents the m-line in the RS, then metadata on it probably doesn't make much sense.) Thanks Paul > John Elwell > Tel: +44 1908 817801 (office and mobile) > Email: john.elwell@siemens-enterprise.com > http://www.siemens-enterprise.com/uk/ > > Siemens Enterprise Communications Limited. > Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. > Registered No: 5903714, England. > > Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG. > > >> >> Thanks, >> Paul >> >>> For example, the schema might look something like this: >>> >>> >> minOccurs="0" maxOccurs="unbounded"/> >>> >> minOccurs="0" maxOccurs="unbounded"/> >>> >>> >>> >>> >> minOccurs="0" maxOccurs="1"/> >>> >> minOccurs="0"/> >>> >> minOccurs="0"/> >>> >> minOccurs="0"/> >>> >>> >>> >>> John >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> From Leon.Portman@nice.com Wed Aug 10 06:58:04 2011 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 70CAA21F8A69 for ; Wed, 10 Aug 2011 06:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 H8hPMm6D0Mzh for ; Wed, 10 Aug 2011 06:58:03 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 78B1021F86B1 for ; Wed, 10 Aug 2011 06:57:30 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Wed, 10 Aug 2011 16:58:00 +0300 From: Leon Portman To: Paul Kyzivat , "Elwell, John" Date: Wed, 10 Aug 2011 16:57:58 +0300 Thread-Topic: [siprec] Do we need a stream element? Thread-Index: AcxV+dLX3pDIVhzSSHiFe6d7TlcwhQBa4/Sw Message-ID: <07465C1D981ABC41A344374066AE1A2C38B0304DA2@TLVMBX01.nice.com> References: <4E3BFC29.6050001@alum.mit.edu> <4E402C2F.1080103@alum.mit.edu> In-Reply-To: <4E402C2F.1080103@alum.mit.edu> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Do we need a stream element? 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, 10 Aug 2011 13:58:04 -0000 I also think it will be cleaner to have dedicated MS element. We can think = about scenarios where it can be "reused" by different participants. Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: Monday, August 08, 2011 9:34 PM To: Elwell, John Cc: siprec@ietf.org Subject: Re: [siprec] Do we need a stream element? On 8/8/11 4:08 AM, Elwell, John wrote: > > >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 05 August 2011 15:20 >> To: siprec@ietf.org >> Subject: Re: [siprec] Do we need a stream element? >> >> John, >> >> On 8/5/11 5:03 AM, Elwell, John wrote: >>> (as individual) >>> >>> Do we need a stream element in the XML? In Quebec we said >> start and stop times should be tied to the association between=20 >> participant and stream, not to the stream itself. >> This seems to suggest they be part of the send and recv sub-elements=20 >> of a participant element. The mode element also seems not to be=20 >> needed, since mixed or separate can be deduced from other=20 >> information. The only relevant information seems to be the label. >>> >>> So it seems to be a waste of space for send and recv >> sub-elements of a participant element to contain a unique ID pointing=20 >> to a stream element that then just contains a label. >> Why don't the send and recv elements simply contain the label (plus=20 >> start and stop times, to meet what was decided in Quebec)? >>> >>> In other words, the MediaStream element in the model is >> entirely represented by a media description in SDP. >> >> I think your point here is that the stream "class" will still exist=20 >> in the model, but its conveyed entirely in SDP and thus does not need=20 >> an xml representation. >> >> One thing the xml element provides is a way to assign a true globally=20 >> unique id, which allows the same stream to be referenced from=20 >> multiple recording sessions. Until now, we have not stated that=20 >> labels are unique ids. Rather, we have said (at least informally)=20 >> that the labels are transient, used to bind the stream xml to the SDP=20 >> within a single message. > [JRE] From past discussions, I am led to believe that a stream element re= presents an RS stream, and therefore the idea of having a unique ID that wo= rks from different RSs doesn't seem relevant. I suspect maybe we are still not all on the same page about this. Lets consider the case of a UA that is its own SRC. I pick that case=20 simply because it is then plausible that it knows a fair amount about=20 the things it is recording. For instance, it might be an office phone, P, in an office that gets a=20 lot of calls and wants to record them all. It could establish an RS at=20 the beginning of the day, and use it for all calls in which it is involved. Assume P makes a voice call to A. Then after that completes, P gets a=20 call from B, and that completes. If P does its own mixing, then it needs only a single m-line in the RS=20 to accomplish this, using if first for the call with A and then for the=20 call with B. The question is whether that is one MS object, or two. There will be two session elements, one for each call. Each will refer=20 to one MS element - either the same one, or a different one. If its a=20 single one, then for the duration of the first call the participants of=20 the MS will be P and A, while during the 2nd call the participants will=20 be P & B. Is that enough for the SRS to understand what is going on? It gets more complex of the two calls are overlapped in time. Perhaps=20 the call from B comes before the call with A is over. So P puts A on=20 hold, answers and completes the call with B and then resumes the call=20 with A. In that case, if there is no MoH, P may still need only a single m-line=20 in the RS to handle this. Then, the participants for the only MS are=20 first P&A, then P&B, then P&A. The MS would then need to be switched=20 from the first session, to the second, and back to the first. I think this *can* work either way, and is to some extent a matter of=20 taste. But it has to be carefully documented one way or the other. In=20 *my* mind having separate MS objects makes sense, but maybe that is just=20 a bias on my part. Thanks, Paul >> I suppose we *could* specify a UUID representation that can >> be used as a >> label in SDP. (That is possible, but would have to be an >> unusual radix64 >> representation, or we could use hex.) >> >> I'm a bit reluctant to go this way because it eliminates the >> opportunity >> to associate other data with a stream, including extension data. But >> lets discuss it further. > [JRE] I see your point, but would such extension data be more appropriate= as part of a send or recv element? I think either place could make sense, but for different things. If you have data about why the sending is taking place or what it is=20 about, then that belongs on the element. If you have data on why=20 the stream as a whole exists, regardless of sender, then extending the=20 MS makes more sense. (But if the MS merely represents the m-line in the=20 RS, then metadata on it probably doesn't make much sense.) Thanks Paul > John Elwell > Tel: +44 1908 817801 (office and mobile) > Email: john.elwell@siemens-enterprise.com > http://www.siemens-enterprise.com/uk/ > > Siemens Enterprise Communications Limited. > Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ= . > Registered No: 5903714, England. > > Siemens Enterprise Communications Limited is a Trademark Licensee of Siem= ens AG. > > >> >> Thanks, >> Paul >> >>> For example, the schema might look something like this: >>> >>> >> minOccurs=3D"0" maxOccurs=3D"unbounded"/> >>> >> minOccurs=3D"0" maxOccurs=3D"unbounded"/> >>> >>> >>> >>> >> minOccurs=3D"0" maxOccurs=3D"1"/> >>> >> minOccurs=3D"0"/> >>> >> minOccurs=3D"0"/> >>> >> minOccurs=3D"0"/> >>> >>> >>> >>> John >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From gonzalo.camarillo@ericsson.com Wed Aug 10 23:18:50 2011 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 C105E21F8588 for ; Wed, 10 Aug 2011 23:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.589 X-Spam-Level: X-Spam-Status: No, score=-106.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HfKuw+ixcZP for ; Wed, 10 Aug 2011 23:18:50 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0B74C21F8564 for ; Wed, 10 Aug 2011 23:18:49 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-3d-4e43746a34de Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 27.1B.09774.A64734E4; Thu, 11 Aug 2011 08:19:22 +0200 (CEST) Received: from [131.160.126.254] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Thu, 11 Aug 2011 08:19:22 +0200 Message-ID: <4E43746A.9070905@ericsson.com> Date: Thu, 11 Aug 2011 09:19:22 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: siprec@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [siprec] New chair for SIPREC 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, 11 Aug 2011 06:18:50 -0000 Folks, Andrew Hutton is going to replace John Elwell as cochair of SIPREC. In order to get Andrew up to speed as fast as possible, John and Andrew will have a period of overlap. That is, John will be stepping down after the virtual interim meeting. I would also like to thank John for all his excellent work driving this group. Cheers, Gonzalo From john.elwell@siemens-enterprise.com Thu Aug 11 00:38:19 2011 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 19CEC21F86D2 for ; Thu, 11 Aug 2011 00:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.4 X-Spam-Level: X-Spam-Status: No, score=-103.4 tagged_above=-999 required=5 tests=[AWL=-0.801, 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 ZE47B9Kkstep for ; Thu, 11 Aug 2011 00:38:18 -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 2213C21F86D0 for ; Thu, 11 Aug 2011 00:38:18 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 8660623F046B for ; Thu, 11 Aug 2011 09:38:48 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 11 Aug 2011 09:38:48 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Thu, 11 Aug 2011 09:38:47 +0200 Thread-Topic: Interim meeting Thread-Index: AcxX+bTbJmyMqrXqSk2HcbJKekEBow== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Interim meeting 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, 11 Aug 2011 07:38:19 -0000 The chairs received insufficient firm commitment to a face-to-face interim = in September. Therefore a virtual interim meeting will take place, split over two days: - Monday 2011-09-19, 14-00-16.00 GMT http://www.timeanddate.com/worldclock/fixedtime.html?msg=3DSIPREC_interim_p= art1&iso=3D20110919T14&ah=3D2 - Friday 2011-09-23, 13.00-15.00 GMT http://www.timeanddate.com/worldclock/fixedtime.html?msg=3DSIPREC_interim_p= art2&iso=3D20110923T13&ah=3D2=20 (note the different times) The Doodle polls are now closed. John= From Ofir.Roth@nice.com Wed Aug 10 03:59:25 2011 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 ED2D821F8757 for ; Wed, 10 Aug 2011 03:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuBStBUtgJRt for ; Wed, 10 Aug 2011 03:59:25 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 637C221F8764 for ; Wed, 10 Aug 2011 03:59:24 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Wed, 10 Aug 2011 13:59:52 +0300 From: Ofir Roth To: "siprec@ietf.org" Date: Wed, 10 Aug 2011 13:59:51 +0300 Thread-Topic: Metadata schema - missing group element in element recording Thread-Index: AcxXTJquqGjtR5XATL25Utt2WXBOjA== Message-ID: Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: multipart/alternative; boundary="_000_D6FF53BFD24F6F448C70DEF68DB4E66555B8CF5C5ATLVMBX01nicec_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 11 Aug 2011 00:39:50 -0700 Subject: [siprec] Metadata schema - missing group element in element 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, 10 Aug 2011 11:25:16 -0000 --_000_D6FF53BFD24F6F448C70DEF68DB4E66555B8CF5C5ATLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, My name is Ofir and I am a software developer in NICE Systems. I have reviewed the XML schema defining the metadata (http://datatracker.ie= tf.org/doc/draft-ietf-siprec-metadata/?include_text=3D1) and noticed that "= group" element is missing from the sequence of "recording" element. It is d= efined as a standalone element but should also be embedded in the recording= element. Please advise. Thanks, Ofir. --_000_D6FF53BFD24F6F448C70DEF68DB4E66555B8CF5C5ATLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

My name is= Ofir and I am a software developer in NICE Systems.
I have reviewed th= e XML schema defining the metadata (http://datatracker.ietf.o= rg/doc/draft-ietf-siprec-metadata/?include_text=3D1) and noticed that &= #8220;group” element is missing from the sequence of “recording= ” element. It is defined as a standalone element but should also be e= mbedded in the recording element.

&= nbsp;

<xs:complex= Type name=3D"recording">

       = <xs:sequence>

           &l= t;xs:element name=3D"datamode" type=3D"dataMode"

  &n= bsp;            = ; minOccurs=3D"0"/>

        &n= bsp;  <xs:element name=3D"session" type=3D"session&q= uot;

&nb= sp;            =    minOccurs=3D"0" maxOccurs=3D"unbounded"/&g= t;

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:black'> = ;          <xs:element name= =3D"participant" type=3D"participant"=

    &= nbsp;           minOccurs= =3D"0" maxOccurs=3D"unbounded"/>

    &nb= sp;      <xs:element name=3D"stream" = type=3D"stream"

         &= nbsp;     minOccurs=3D"0" maxOccurs=3D"u= nbounded"/>

         <xs:element= name=3D"extensiondata" type=3D"extensiondata"

  &nb= sp;            minOc= curs=3D"0" maxOccurs=3D"unbounded"/>

    = ;   </xs:sequence>

   </xs:complexType><= /span>

 

Pl= ease advise.

 

Thanks,

Ofir.<= /p>

 

= --_000_D6FF53BFD24F6F448C70DEF68DB4E66555B8CF5C5ATLVMBX01nicec_-- From pkyzivat@alum.mit.edu Thu Aug 11 06:04:29 2011 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 69DE721F86F6 for ; Thu, 11 Aug 2011 06:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 qtXuBJm5Xrgg for ; Thu, 11 Aug 2011 06:04:28 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id B0F1521F854D for ; Thu, 11 Aug 2011 06:04:28 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta04.westchester.pa.mail.comcast.net with comcast id K0aW1h0011wpRvQ54153b6; Thu, 11 Aug 2011 13:05:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta18.westchester.pa.mail.comcast.net with comcast id K1531h0020tdiYw3e153Rt; Thu, 11 Aug 2011 13:05:03 +0000 Message-ID: <4E43D37D.2030603@alum.mit.edu> Date: Thu, 11 Aug 2011 09:05:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: siprec@ietf.org References: <4E43746A.9070905@ericsson.com> In-Reply-To: <4E43746A.9070905@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] New chair for SIPREC 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, 11 Aug 2011 13:04:29 -0000 John - thanks for the more than excellent chairing, keeping the cats well herded. SIPREC has been among the best run wgs I have experienced. And best wishes in your retirement. Andrew - congratulations. You have big shoes to fill. Thanks, Paul On 8/11/11 2:19 AM, Gonzalo Camarillo wrote: > Folks, > > Andrew Hutton is going to replace John Elwell as cochair of SIPREC. In > order to get Andrew up to speed as fast as possible, John and Andrew > will have a period of overlap. That is, John will be stepping down after > the virtual interim meeting. > > I would also like to thank John for all his excellent work driving this > group. > > Cheers, > > Gonzalo > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From leon.portman@gmail.com Thu Aug 11 07:05:50 2011 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 D7F1E21F8559 for ; Thu, 11 Aug 2011 07:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0q-69WOfIxq for ; Thu, 11 Aug 2011 07:05:50 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3784621F854E for ; Thu, 11 Aug 2011 07:05:50 -0700 (PDT) Received: by wwf5 with SMTP id 5so1494338wwf.13 for ; Thu, 11 Aug 2011 07:06:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=ep3xOg1uPvccgU6D2z71PN/KTvkpcwIK/K0zOAuCU/o=; b=UDvH3MsV1eOW8RvZfz1KmlF0MfQ73haejuvdAFEE1fSdGMlP7BB4EOGjQrJnNAlxV3 RCjw6mqbHV7W+rBzQydFEHST8OHazqlAVQrkmfQJw4s7YWcToTVxY9p2v+yasROHyuin GX3T0AWBmBOfEHG6MY9UQIaRdmKsrHVrysU64= Received: by 10.227.7.27 with SMTP id b27mr155215wbb.24.1313071584081; Thu, 11 Aug 2011 07:06:24 -0700 (PDT) Received: from [192.168.1.106] ([212.150.140.190]) by mx.google.com with ESMTPS id ff6sm1582857wbb.15.2011.08.11.07.06.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Aug 2011 07:06:22 -0700 (PDT) References: <4E43746A.9070905@ericsson.com> <4E43D37D.2030603@alum.mit.edu> In-Reply-To: <4E43D37D.2030603@alum.mit.edu> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <602D7898-5FC8-42F8-8A8A-482589F89D0F@gmail.com> X-Mailer: iPad Mail (9A5288d) From: Leon Portman Date: Thu, 11 Aug 2011 17:06:22 +0300 To: Paul Kyzivat Cc: "siprec@ietf.org" Subject: Re: [siprec] New chair for SIPREC 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, 11 Aug 2011 14:05:51 -0000 +1=20 Leon Sent from my iPad On 11 =D7=91=D7=90=D7=95=D7=92 2011, at 16:05, Paul Kyzivat wrote: > John - thanks for the more than excellent chairing, keeping the cats well h= erded. SIPREC has been among the best run wgs I have experienced. And best w= ishes in your retirement. >=20 > Andrew - congratulations. You have big shoes to fill. >=20 > Thanks, > Paul >=20 > On 8/11/11 2:19 AM, Gonzalo Camarillo wrote: >> Folks, >>=20 >> Andrew Hutton is going to replace John Elwell as cochair of SIPREC. In >> order to get Andrew up to speed as fast as possible, John and Andrew >> will have a period of overlap. That is, John will be stepping down after >> the virtual interim meeting. >>=20 >> I would also like to thank John for all his excellent work driving this >> group. >>=20 >> Cheers, >>=20 >> Gonzalo >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >>=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Thu Aug 11 08:44:01 2011 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 935A121F8781 for ; Thu, 11 Aug 2011 08:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.85 X-Spam-Level: X-Spam-Status: No, score=-2.85 tagged_above=-999 required=5 tests=[AWL=-0.251, 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 YhDhybG2ENcK for ; Thu, 11 Aug 2011 08:44:00 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFC921F8770 for ; Thu, 11 Aug 2011 08:43:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=8443; q=dns/txt; s=iport; t=1313077475; x=1314287075; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=XV4M5Lra3ByRHHU60MRgv6nCdriBLiKt+pR4+C2ScMg=; b=aXtBrCj2HcJxG4FBtZZdSRB24n3o+F7H01mO3XFTdIVmZ26SzaLEYjkg i0U2pjSAkMcBD77yLwJPcTy0TDmwM1iL2iwNjvu4TL6ivzbS1e1GO9ib2 0SHxfxYCulcwCppii1Ngwxbf0BzK906wNuHGl4fkF0D6SnTH8kZIYdWWS M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtAAAJ34Q06rRDoJ/2dsb2JhbAA7Bg6Xc49Jd4FAAQEBAQMBAQEPAR0KNAsMBAIBCBEEAQEBCgYXAQYBJh8JCAEBBAESCBqHUZ1sAZ5ygzGCN18Eh1+QQ4sjWA X-IronPort-AV: E=Sophos;i="4.67,357,1309737600"; d="scan'208";a="12230386" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-4.cisco.com with ESMTP; 11 Aug 2011 15:44:28 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p7BFiR3F030794; Thu, 11 Aug 2011 15:44:27 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Aug 2011 08:44:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 X-CR-Hashedpuzzle: BeNv CkBF CtN0 E7jX PH5f PfJH S0p8 Uy29 VuTz XvDD fn6B hwIl h4qF nLhz oq5t pBB8; 4; agBvAGgAbgAuAGUAbAB3AGUAbABsAEAAcwBpAGUAbQBlAG4AcwAtAGUAbgB0AGUAcgBwAHIAaQBzAGUALgBjAG8AbQA7AGwAZQBvAG4ALgBwAG8AcgB0AG0AYQBuAEAAbgBpAGMAZQAuAGMAbwBtADsAcABrAHkAegBpAHYAYQB0AEAAYQBsAHUAbQAuAG0AaQB0AC4AZQBkAHUAOwBzAGkAcAByAGUAYwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {7ABF44D8-1990-41BB-B22C-28F752CC2F88}; ZQBjAGsAZQBsAGMAdQBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Thu, 11 Aug 2011 15:44:19 GMT; UgBFADoAIABbAHMAaQBwAHIAZQBjAF0AIABEAG8AIAB3AGUAIABuAGUAZQBkACAAYQAgAHMAdAByAGUAYQBtACAAZQBsAGUAbQBlAG4AdAA/AA== MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-CR-Puzzleid: {7ABF44D8-1990-41BB-B22C-28F752CC2F88} Content-class: urn:content-classes:message Date: Thu, 11 Aug 2011 08:44:18 -0700 Message-ID: In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38B0304DA2@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Do we need a stream element? Thread-Index: AcxV+dLX3pDIVhzSSHiFe6d7TlcwhQBa4/SwADW3PdA= References: <4E3BFC29.6050001@alum.mit.edu><4E402C2F.1080103@alum.mit.edu> <07465C1D981ABC41A344374066AE1A2C38B0304DA2@TLVMBX01.nice.com> From: "Charles Eckel (eckelcu)" To: "Leon Portman" , "Paul Kyzivat" , "Elwell, John" X-OriginalArrivalTime: 11 Aug 2011 15:44:27.0770 (UTC) FILETIME=[8D88BDA0:01CC583D] Cc: siprec@ietf.org Subject: Re: [siprec] Do we need a stream element? 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, 11 Aug 2011 15:44:01 -0000 The media stream element was more intuitive to me when I understood it to describe the CS media streams. Now that I understand it to be the RS media streams, I agree with John that the SDP could be sufficient. I believe I understand the points Paul and Leon are making with respect to long duration recordings; however, it does seem to me that we now have multiple mechanisms to describe very similar information (RS SDP, RS media stream, send/recv elements). I would prefer to eliminate some of the redundancy, otherwise I fear we will create duplications, and even worse, inconsistencies.=20 Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman > Sent: Wednesday, August 10, 2011 6:58 AM > To: Paul Kyzivat; Elwell, John > Cc: siprec@ietf.org > Subject: Re: [siprec] Do we need a stream element? >=20 > I also think it will be cleaner to have dedicated MS element. We can think about scenarios where it > can be "reused" by different participants. >=20 > Leon >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, August 08, 2011 9:34 PM > To: Elwell, John > Cc: siprec@ietf.org > Subject: Re: [siprec] Do we need a stream element? >=20 > On 8/8/11 4:08 AM, Elwell, John wrote: > > > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org > >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > >> Sent: 05 August 2011 15:20 > >> To: siprec@ietf.org > >> Subject: Re: [siprec] Do we need a stream element? > >> > >> John, > >> > >> On 8/5/11 5:03 AM, Elwell, John wrote: > >>> (as individual) > >>> > >>> Do we need a stream element in the XML? In Quebec we said > >> start and stop times should be tied to the association between > >> participant and stream, not to the stream itself. > >> This seems to suggest they be part of the send and recv sub-elements > >> of a participant element. The mode element also seems not to be > >> needed, since mixed or separate can be deduced from other > >> information. The only relevant information seems to be the label. > >>> > >>> So it seems to be a waste of space for send and recv > >> sub-elements of a participant element to contain a unique ID pointing > >> to a stream element that then just contains a label. > >> Why don't the send and recv elements simply contain the label (plus > >> start and stop times, to meet what was decided in Quebec)? > >>> > >>> In other words, the MediaStream element in the model is > >> entirely represented by a media description in SDP. > >> > >> I think your point here is that the stream "class" will still exist > >> in the model, but its conveyed entirely in SDP and thus does not need > >> an xml representation. > >> > >> One thing the xml element provides is a way to assign a true globally > >> unique id, which allows the same stream to be referenced from > >> multiple recording sessions. Until now, we have not stated that > >> labels are unique ids. Rather, we have said (at least informally) > >> that the labels are transient, used to bind the stream xml to the SDP > >> within a single message. > > [JRE] From past discussions, I am led to believe that a stream element represents an RS stream, and > therefore the idea of having a unique ID that works from different RSs doesn't seem relevant. >=20 > I suspect maybe we are still not all on the same page about this. >=20 > Lets consider the case of a UA that is its own SRC. I pick that case > simply because it is then plausible that it knows a fair amount about > the things it is recording. >=20 > For instance, it might be an office phone, P, in an office that gets a > lot of calls and wants to record them all. It could establish an RS at > the beginning of the day, and use it for all calls in which it is involved. >=20 > Assume P makes a voice call to A. Then after that completes, P gets a > call from B, and that completes. >=20 > If P does its own mixing, then it needs only a single m-line in the RS > to accomplish this, using if first for the call with A and then for the > call with B. >=20 > The question is whether that is one MS object, or two. >=20 > There will be two session elements, one for each call. Each will refer > to one MS element - either the same one, or a different one. If its a > single one, then for the duration of the first call the participants of > the MS will be P and A, while during the 2nd call the participants will > be P & B. Is that enough for the SRS to understand what is going on? >=20 > It gets more complex of the two calls are overlapped in time. Perhaps > the call from B comes before the call with A is over. So P puts A on > hold, answers and completes the call with B and then resumes the call > with A. >=20 > In that case, if there is no MoH, P may still need only a single m-line > in the RS to handle this. Then, the participants for the only MS are > first P&A, then P&B, then P&A. The MS would then need to be switched > from the first session, to the second, and back to the first. >=20 > I think this *can* work either way, and is to some extent a matter of > taste. But it has to be carefully documented one way or the other. In > *my* mind having separate MS objects makes sense, but maybe that is just > a bias on my part. >=20 > Thanks, > Paul >=20 >=20 > >> I suppose we *could* specify a UUID representation that can > >> be used as a > >> label in SDP. (That is possible, but would have to be an > >> unusual radix64 > >> representation, or we could use hex.) > >> > >> I'm a bit reluctant to go this way because it eliminates the > >> opportunity > >> to associate other data with a stream, including extension data. But > >> lets discuss it further. > > [JRE] I see your point, but would such extension data be more appropriate as part of a send or recv > element? >=20 > I think either place could make sense, but for different things. > If you have data about why the sending is taking place or what it is > about, then that belongs on the element. If you have data on why > the stream as a whole exists, regardless of sender, then extending the > MS makes more sense. (But if the MS merely represents the m-line in the > RS, then metadata on it probably doesn't make much sense.) >=20 > Thanks > Paul >=20 >=20 > > John Elwell > > Tel: +44 1908 817801 (office and mobile) > > Email: john.elwell@siemens-enterprise.com > > http://www.siemens-enterprise.com/uk/ > > > > Siemens Enterprise Communications Limited. > > Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. > > Registered No: 5903714, England. > > > > Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG. > > > > > >> > >> Thanks, > >> Paul > >> > >>> For example, the schema might look something like this: > >>> > >>> >>> minOccurs=3D"0" maxOccurs=3D"unbounded"/> > >>> >>> minOccurs=3D"0" maxOccurs=3D"unbounded"/> > >>> > >>> > >>> > >>> >>> minOccurs=3D"0" maxOccurs=3D"1"/> > >>> >>> minOccurs=3D"0"/> > >>> >>> minOccurs=3D"0"/> > >>> >>> minOccurs=3D"0"/> > >>> > >>> > >>> > >>> John > >>> _______________________________________________ > >>> siprec mailing list > >>> siprec@ietf.org > >>> https://www.ietf.org/mailman/listinfo/siprec > >>> > >> > >> _______________________________________________ > >> siprec mailing list > >> siprec@ietf.org > >> https://www.ietf.org/mailman/listinfo/siprec > >> >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Thu Aug 11 08:54:12 2011 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 B3D0821F8A95 for ; Thu, 11 Aug 2011 08:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.845 X-Spam-Level: X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[AWL=-0.246, 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 Zkv9Biv82Nyi for ; Thu, 11 Aug 2011 08:54:12 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id D908F21F85CA for ; Thu, 11 Aug 2011 08:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=1371; q=dns/txt; s=iport; t=1313078086; x=1314287686; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=jRVy/ZHVmq/5eTaZQIANQhEW2XYUWTBdhiJGkLmcbuM=; b=HTVrkezRqLMxT0k6KCVZoETuDlY9CCnk6CbupT6xvFyUSZN6Zz7DKUyq 61AbPBYhVxwn1vGOCdRI8L+H7phJwGPxht9fllhr0PXiZXwCGnd8RLsci Q6d8mwVBfCRJTEAx/gi+cVUlCXM9F1bGitGrxv9mw8g3URKCjFvGz64YZ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8AAD/6Q06rRDoG/2dsb2JhbABBDpdzj0l3gUABAQEBAwEBAQ8BHQo0FwQCAQgOAwQBAQEKBhcBBgEmHwkIAQEEARIIGodRnXEBnnKFaF8Eh1+QQ4sjWA X-IronPort-AV: E=Sophos;i="4.67,357,1309737600"; d="scan'208";a="12233498" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-1.cisco.com with ESMTP; 11 Aug 2011 15:54:46 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7BFsjrg018144; Thu, 11 Aug 2011 15:54:45 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Aug 2011 08:54:45 -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, 11 Aug 2011 08:54:44 -0700 Message-ID: In-Reply-To: <4E43D37D.2030603@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] New chair for SIPREC Thread-Index: AcxYJ11xXxLpLpgcQouJcrPyRDK7FAAFwlRA References: <4E43746A.9070905@ericsson.com> <4E43D37D.2030603@alum.mit.edu> From: "Charles Eckel (eckelcu)" To: "Paul Kyzivat" , X-OriginalArrivalTime: 11 Aug 2011 15:54:45.0723 (UTC) FILETIME=[FDDCE2B0:01CC583E] Subject: Re: [siprec] New chair for SIPREC 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, 11 Aug 2011 15:54:12 -0000 Very well put. Thanks, congrats, and good luck John and Andy! Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Thursday, August 11, 2011 6:05 AM > To: siprec@ietf.org > Subject: Re: [siprec] New chair for SIPREC >=20 > John - thanks for the more than excellent chairing, keeping the cats > well herded. SIPREC has been among the best run wgs I have experienced. > And best wishes in your retirement. >=20 > Andrew - congratulations. You have big shoes to fill. >=20 > Thanks, > Paul >=20 > On 8/11/11 2:19 AM, Gonzalo Camarillo wrote: > > Folks, > > > > Andrew Hutton is going to replace John Elwell as cochair of SIPREC. In > > order to get Andrew up to speed as fast as possible, John and Andrew > > will have a period of overlap. That is, John will be stepping down after > > the virtual interim meeting. > > > > I would also like to thank John for all his excellent work driving this > > group. > > > > Cheers, > > > > Gonzalo > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From Henry.Lum@alcatel-lucent.com Thu Aug 11 09:37:00 2011 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 2842721F8742 for ; Thu, 11 Aug 2011 09:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 qpFHKod-eTvC for ; Thu, 11 Aug 2011 09:36:59 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 75C0621F86F4 for ; Thu, 11 Aug 2011 09:36:59 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p7BGbTTh003407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Aug 2011 11:37:30 -0500 (CDT) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [172.22.68.187]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p7BGbScW009294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Aug 2011 11:37:29 -0500 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 p7BGbR4t028584; Thu, 11 Aug 2011 09:37:27 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Aug 2011 09:37:27 -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, 11 Aug 2011 09:37:50 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF740766EF17@NAHALD.us.int.genesyslab.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] New chair for SIPREC Thread-Index: AcxYJ11xXxLpLpgcQouJcrPyRDK7FAAFwlRAAAGjL4A= References: <4E43746A.9070905@ericsson.com> <4E43D37D.2030603@alum.mit.edu> From: "Henry Lum" To: "Charles Eckel (eckelcu)" , "Paul Kyzivat" , X-OriginalArrivalTime: 11 Aug 2011 16:37:27.0324 (UTC) FILETIME=[F4B22DC0:01CC5844] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [siprec] New chair for SIPREC 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, 11 Aug 2011 16:37:00 -0000 Thanks John and Andy! -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu) Sent: Thursday, August 11, 2011 11:55 AM To: Paul Kyzivat; siprec@ietf.org Subject: Re: [siprec] New chair for SIPREC Very well put. Thanks, congrats, and good luck John and Andy! Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Thursday, August 11, 2011 6:05 AM > To: siprec@ietf.org > Subject: Re: [siprec] New chair for SIPREC >=20 > John - thanks for the more than excellent chairing, keeping the cats > well herded. SIPREC has been among the best run wgs I have experienced. > And best wishes in your retirement. >=20 > Andrew - congratulations. You have big shoes to fill. >=20 > Thanks, > Paul >=20 > On 8/11/11 2:19 AM, Gonzalo Camarillo wrote: > > Folks, > > > > Andrew Hutton is going to replace John Elwell as cochair of SIPREC. In > > order to get Andrew up to speed as fast as possible, John and Andrew > > will have a period of overlap. That is, John will be stepping down after > > the virtual interim meeting. > > > > I would also like to thank John for all his excellent work driving this > > group. > > > > Cheers, > > > > Gonzalo > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From wwwrun@ietfa.amsl.com Thu Aug 11 14:19:30 2011 Return-Path: X-Original-To: siprec@ietf.org Delivered-To: siprec@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 00B1621F8B5F; Thu, 11 Aug 2011 14:19:29 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110811211930.00B1621F8B5F@ietfa.amsl.com> Date: Thu, 11 Aug 2011 14:19:29 -0700 (PDT) Cc: siprec@ietf.org Subject: [siprec] SIPREC WG Virtual Interim Meetings: September 19 & September 23, 2011 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, 11 Aug 2011 21:19:30 -0000 The SIPREC WG will hold an interim virtual meeting in two sessions on: - Monday 2011-09-19, 14-00-16.00 GMT http://www.timeanddate.com/worldclock/fixedtime.html?msg=SIPREC_interim_part1&iso=20110919T14&ah=2 - Friday 2011-09-23, 13.00-15.00 GMT http://www.timeanddate.com/worldclock/fixedtime.html?msg=SIPREC_interim_part2&iso=20110923T13&ah=2 Agenda and details will be announced on the SIPREC mailing list (http://www.ietf.org/mail-archive/web/siprec/) in due course. From wwwrun@rfc-editor.org Fri Aug 12 16:57:11 2011 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 EA86B21F84F2; Fri, 12 Aug 2011 16:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.062 X-Spam-Level: X-Spam-Status: No, score=-102.062 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, 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 4FxijDZPeDAE; Fri, 12 Aug 2011 16:57:11 -0700 (PDT) Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id 6A25621F84E6; Fri, 12 Aug 2011 16:57:11 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id EAA2498C247; Fri, 12 Aug 2011 16:57:49 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110812235749.EAA2498C247@rfc-editor.org> Date: Fri, 12 Aug 2011 16:57:49 -0700 (PDT) Cc: siprec@ietf.org, rfc-editor@rfc-editor.org Subject: [siprec] RFC 6341 on Use Cases and Requirements for SIP-Based Media Recording (SIPREC) 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, 12 Aug 2011 23:57:12 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6341 Title: Use Cases and Requirements for SIP-Based Media Recording (SIPREC) Author: K. Rehor, Ed., L. Portman, Ed., A. Hutton, R. Jain Status: Informational Stream: IETF Date: August 2011 Mailbox: krehor@cisco.com, leon.portman@nice.com, andrew.hutton@siemens-enterprise.com, rajnish.jain@ipc.com Pages: 16 Characters: 34155 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-siprec-req-12.txt URL: http://www.rfc-editor.org/rfc/rfc6341.txt Session recording is a critical requirement in many business communications environments, such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control or business analytics. Recording is typically performed by sending a copy of the session media to the recording devices. This document specifies requirements for extensions to SIP that will manage delivery of RTP media to a recording device. This is being referred to as SIP-based Media Recording. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the SIP Recording Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From john.elwell@siemens-enterprise.com Mon Aug 15 00:06:15 2011 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 CD2AB21F8742 for ; Mon, 15 Aug 2011 00:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.383 X-Spam-Level: X-Spam-Status: No, score=-104.383 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, 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 U9ojMiwym82G for ; Mon, 15 Aug 2011 00:06:14 -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 5F07F21F8745 for ; Mon, 15 Aug 2011 00:06:14 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 0E5321EB83F7 for ; Mon, 15 Aug 2011 09:06:58 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 15 Aug 2011 09:06:58 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Mon, 15 Aug 2011 09:06:57 +0200 Thread-Topic: Meeting invitation: SIPREC WG Virtual Interim Meeting Session 2 (Friday 23rd September) Thread-Index: AcxYbwOYl45JHC0vS+6wMVb+dsZXMQCqqoAA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A444A0F8084434499206E78C106220CA09BDABFBC0MCHP058Agloba_" MIME-Version: 1.0 Subject: [siprec] FW: Meeting invitation: SIPREC WG Virtual Interim Meeting Session 2 (Friday 23rd September) 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, 15 Aug 2011 07:06:15 -0000 --_000_A444A0F8084434499206E78C106220CA09BDABFBC0MCHP058Agloba_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ________________________________ From: IETF Secretariat [mailto:messenger@webex.com] Sent: 11 August 2011 22:38 To: Elwell, John Subject: Meeting invitation: SIPREC WG Virtual Interim Meeting 2 Hello , IETF Secretariat invites you to attend this online meeting. Topic: SIPREC WG Virtual Interim Meeting 2 Date: Friday, September 23, 2011 Time: 6:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 965 570 355 Meeting Password: (This meeting does not require a password.) ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=3D181789567&UID=3D1= 249261672&RT=3DMiM0 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: (This meeting doe= s not require a password.) 4. Click "Join". To view in other time zones or languages, please click the link: https://workgreen.webex.com/workgreen/j.php?ED=3D181789567&UID=3D1249261672= &ORT=3DMiM0 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll number (US/Canada): 1-408-792-6300 Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.= php?serviceType=3DMC&ED=3D181789567&tollFree=3D0 Access code:965 570 355 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/mc 2. On the left navigation bar, click "Support". You can contact me at: amorris@amsl.com 1-510-492-4081 To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link: https://workgreen.webex.com/workgreen/j.php?ED=3D181789567&UID=3D1249261672= &ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DKK2Dd7kffEOzG-9-E9eIYKvcsDQWxVvR5qnQO= FwFXJ4=3D&RT=3DMiM0 The playback of UCF (Universal Communications Format) rich media files requ= ires appropriate players. To view this type of rich media files in the meet= ing, please check whether you have the players installed on your computer b= y going to https://workgreen.webex.com/workgreen/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+14087926300x965570355# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. --_000_A444A0F8084434499206E78C106220CA09BDABFBC0MCHP058Agloba_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 

From: IETF Secretariat=20 [mailto:messenger@webex.com]
Sent: 11 August 2011=20 22:38
To: Elwell, John
Subject: Meeting invitation: S= IPREC=20 WG Virtual Interim Meeting 2


Hello ,
IETF=20 Secretariat invites you to attend this online meeting.

Topic: SIP= REC=20 WG Virtual Interim Meeting 2
Date: Friday, September 23, 2011
Tim= e:=20 6:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)
Meeting Num= ber:=20 965 570 355
Meeting Password: (This meeting does not require a passwo= rd.)=20


-------------------------------------------------------
T= o=20 join the online meeting (Now from mobile devices!)=20
-------------------------------------------------------
1. Go to = https://workgreen.webex.com/workgreen/j.php?ED=3D18178956= 7&UID=3D1249261672&RT=3DMiM0=20
2. If requested, enter your name and email address.
3. If a passw= ord=20 is required, enter the meeting password: (This meeting does not require a= =20 password.)
4. Click "Join".

To view in other time zones or=20 languages, please click the link:
https://workgreen.webex.com/workgreen/j.php?ED=3D18178956= 7&UID=3D1249261672&ORT=3DMiM0=20

-------------------------------------------------------
To jo= in=20 the audio conference only=20
-------------------------------------------------------
To receiv= e a=20 call back, provide your phone number when you join the meeting, or call t= he=20 number below and enter the access code.
Call-in toll number (US/Canad= a):=20 1-408-792-6300
Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?se= rviceType=3DMC&ED=3D181789567&tollFree=3D0=20

Access code:965 570 355=20

-------------------------------------------------------
For=20 assistance
------------------------------------------------------- 1.=20 Go to https://workgreen.webex.com/workgreen/mc
2. On th= e left=20 navigation bar, click "Support".

You can contact me at:
amorris@amsl.com
1-510-492-4081= =20

To add this meeting to your calendar program (for example Microso= ft=20 Outlook), click this link:
https://workgreen.webex.com/workgreen/j.php?ED=3D18178956= 7&UID=3D1249261672&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SH= A2=3DKK2Dd7kffEOzG-9-E9eIYKvcsDQWxVvR5qnQOFwFXJ4=3D&RT=3DMiM0=20

The playback of UCF (Universal Communications Format) rich media = files=20 requires appropriate players. To view this type of rich media files in th= e=20 meeting, please check whether you have the players installed on your comp= uter=20 by going to https:= //workgreen.webex.com/workgreen/systemdiagnosis.php.=20

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial

http://www.webex.com=20

CCP:+14087926300x965570355#

IMPORTANT NOTICE: This WebEx= =20 service includes a feature that allows audio and any documents and other= =20 materials exchanged or viewed during the session to be recorded. By joini= ng=20 this session, you automatically consent to such recordings. If you do not= =20 consent to the recording, discuss your concerns with the meeting host pri= or to=20 the start of the recording or do not join the session. Please note that a= ny=20 such recordings may be subject to discovery in the event of litigation.=20
--_000_A444A0F8084434499206E78C106220CA09BDABFBC0MCHP058Agloba_-- From john.elwell@siemens-enterprise.com Mon Aug 15 00:06:15 2011 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 DDFE621F8745 for ; Mon, 15 Aug 2011 00:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.386 X-Spam-Level: X-Spam-Status: No, score=-104.386 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, 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 CDKDjyryIVko for ; Mon, 15 Aug 2011 00:06: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 5EBDE21F85F2 for ; Mon, 15 Aug 2011 00:06:14 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 0DCA023F046A for ; Mon, 15 Aug 2011 09:06:55 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 15 Aug 2011 09:06:55 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Mon, 15 Aug 2011 09:06:53 +0200 Thread-Topic: Meeting invitation: SIPREC WG Virtual Interim Meeting Session 1 (Monday 19th September) Thread-Index: AcxYbqV6e/Wm+VhDTa6T8/vUgzM9IwCqugsA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A444A0F8084434499206E78C106220CA09BDABFBBFMCHP058Agloba_" MIME-Version: 1.0 Subject: [siprec] FW: Meeting invitation: SIPREC WG Virtual Interim Meeting Session 1 (Monday 19th September) 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, 15 Aug 2011 07:06:16 -0000 --_000_A444A0F8084434499206E78C106220CA09BDABFBBFMCHP058Agloba_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ________________________________ From: IETF Secretariat [mailto:messenger@webex.com] Sent: 11 August 2011 22:36 To: Elwell, John Subject: Meeting invitation: SIPREC WG Virtual Interim Meeting 1 Hello , IETF Secretariat invites you to attend this online meeting. Topic: SIPREC WG Virtual Interim Meeting 1 Date: Monday, September 19, 2011 Time: 7:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 965 497 445 Meeting Password: (This meeting does not require a password.) ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=3D181789547&UID=3D1= 249261402&RT=3DMiM0 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: (This meeting doe= s not require a password.) 4. Click "Join". To view in other time zones or languages, please click the link: https://workgreen.webex.com/workgreen/j.php?ED=3D181789547&UID=3D1249261402= &ORT=3DMiM0 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): 1-866-699-3239 Call-in toll number (US/Canada): 1-408-792-6300 Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.= php?serviceType=3DMC&ED=3D181789547&tollFree=3D1 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:965 497 445 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/mc 2. On the left navigation bar, click "Support". You can contact me at: amorris@amsl.com 1-510-492-4081 To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link: https://workgreen.webex.com/workgreen/j.php?ED=3D181789547&UID=3D1249261402= &ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DEgRBY75T8lTBZrISUEn-TS5lQhd5x5dpy8itA= 4wRSd8=3D&RT=3DMiM0 The playback of UCF (Universal Communications Format) rich media files requ= ires appropriate players. To view this type of rich media files in the meet= ing, please check whether you have the players installed on your computer b= y going to https://workgreen.webex.com/workgreen/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+14087926300x965497445# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. --_000_A444A0F8084434499206E78C106220CA09BDABFBBFMCHP058Agloba_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 

From: IETF Secretariat=20 [mailto:messenger@webex.com]
Sent: 11 August 2011=20 22:36
To: Elwell, John
Subject: Meeting invitation: S= IPREC=20 WG Virtual Interim Meeting 1


Hello ,
IETF=20 Secretariat invites you to attend this online meeting.

Topic: SIP= REC=20 WG Virtual Interim Meeting 1
Date: Monday, September 19, 2011
Tim= e:=20 7:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)
Meeting Num= ber:=20 965 497 445
Meeting Password: (This meeting does not require a passwo= rd.)=20


-------------------------------------------------------
T= o=20 join the online meeting (Now from mobile devices!)=20
-------------------------------------------------------
1. Go to = https://workgreen.webex.com/workgreen/j.php?ED=3D18178954= 7&UID=3D1249261402&RT=3DMiM0=20
2. If requested, enter your name and email address.
3. If a passw= ord=20 is required, enter the meeting password: (This meeting does not require a= =20 password.)
4. Click "Join".

To view in other time zones or=20 languages, please click the link:
https://workgreen.webex.com/workgreen/j.php?ED=3D18178954= 7&UID=3D1249261402&ORT=3DMiM0=20

-------------------------------------------------------
To jo= in=20 the audio conference only=20
-------------------------------------------------------
To receiv= e a=20 call back, provide your phone number when you join the meeting, or call t= he=20 number below and enter the access code.
Call-in toll-free number=20 (US/Canada): 1-866-699-3239
Call-in toll number (US/Canada):=20 1-408-792-6300
Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?se= rviceType=3DMC&ED=3D181789547&tollFree=3D1=20
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf=20

Access code:965 497 445=20

-------------------------------------------------------
For=20 assistance
------------------------------------------------------- 1.=20 Go to https://workgreen.webex.com/workgreen/mc
2. On th= e left=20 navigation bar, click "Support".

You can contact me at:
amorris@amsl.com
1-510-492-4081= =20

To add this meeting to your calendar program (for example Microso= ft=20 Outlook), click this link:
https://workgreen.webex.com/workgreen/j.php?ED=3D18178954= 7&UID=3D1249261402&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SH= A2=3DEgRBY75T8lTBZrISUEn-TS5lQhd5x5dpy8itA4wRSd8=3D&RT=3DMiM0=20

The playback of UCF (Universal Communications Format) rich media = files=20 requires appropriate players. To view this type of rich media files in th= e=20 meeting, please check whether you have the players installed on your comp= uter=20 by going to https:= //workgreen.webex.com/workgreen/systemdiagnosis.php.=20

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial

http://www.webex.com=20

CCP:+14087926300x965497445#

IMPORTANT NOTICE: This WebEx= =20 service includes a feature that allows audio and any documents and other= =20 materials exchanged or viewed during the session to be recorded. By joini= ng=20 this session, you automatically consent to such recordings. If you do not= =20 consent to the recording, discuss your concerns with the meeting host pri= or to=20 the start of the recording or do not join the session. Please note that a= ny=20 such recordings may be subject to discovery in the event of litigation.=20
--_000_A444A0F8084434499206E78C106220CA09BDABFBBFMCHP058Agloba_-- From john.elwell@siemens-enterprise.com Mon Aug 15 00:28:40 2011 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 6AE6521F86BC for ; Mon, 15 Aug 2011 00:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.388 X-Spam-Level: X-Spam-Status: No, score=-103.388 tagged_above=-999 required=5 tests=[AWL=-0.789, 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 wE5yR9pu73Al for ; Mon, 15 Aug 2011 00:28:39 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7161E21F8570 for ; Mon, 15 Aug 2011 00:28:39 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 0862C1EB83ED for ; Mon, 15 Aug 2011 09:29:24 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 15 Aug 2011 09:29:24 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Mon, 15 Aug 2011 09:29:22 +0200 Thread-Topic: Consensus calls from Quebec Thread-Index: AcxSiVrjTGEpg3bpR0yZYzzWcpQl0AIkxZ1g Message-ID: Keywords: SIPREC 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] Consensus calls from Quebec 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, 15 Aug 2011 07:28:40 -0000 I saw no further discussion, so we seem to have consensus on the issues bel= ow. Would the editors please incorporate these changes in draft-ietf-siprec= -metadata-04 and draft-ietf-siprec-protocol-00? Thanks, John > -----Original Message----- > From: Elwell, John=20 > Sent: 04 August 2011 10:32 > To: siprec@ietf.org > Subject: Consensus calls from Quebec >=20 > The following were agreed at the Quebec face-to-face. Please=20 > raise any objections by 2011-08-14. >=20 > Metadata: > - Include associate/dissociate times for Participant in a CS. > - A Participant can exist outside the context of a CS or CSG. > - Contact header field parameters to be included as an=20 > attribute of an association between Participant and CS. > - Multiple identifiers to be allowed for a Participant. > - Metadata to include information to associate a Participant=20 > with a CSRC value. > - All receiving Participants are to be explicitly indicated=20 > (no receive by default). >=20 > Protocol: > - Proceed with snapshot request to recover from=20 > synchronization issues (but not syntax errors). > - Inclusion of sequence number in metadata XML. > - A snapshot request to lead to repeat of SDP (offer-answer)=20 > in addition to re-sending of XML. > - Addition of option tag(s) so that they can be used in=20 > Require to ensure RS failure if non-compliant UA encountered. > - Adoption of draft as WG item (note that it will not at this=20 > stage include RTP text - that will be adopted later). >=20 > John >=20 >=20 >=20 > John Elwell > Tel: +44 1908 817801 (office and mobile) > Email: john.elwell@siemens-enterprise.com > http://www.siemens-enterprise.com/uk/ >=20 > Siemens Enterprise Communications Limited. > Registered office: Brickhill Street, Willen Lake, Milton=20 > Keynes, MK15 0DJ. > Registered No: 5903714, England. >=20 > Siemens Enterprise Communications Limited is a Trademark=20 > Licensee of Siemens AG. > = From john.elwell@siemens-enterprise.com Mon Aug 15 00:32:19 2011 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 7AEDF21F8520 for ; Mon, 15 Aug 2011 00:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.381 X-Spam-Level: X-Spam-Status: No, score=-103.381 tagged_above=-999 required=5 tests=[AWL=-0.782, 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 6S911MespMKl for ; Mon, 15 Aug 2011 00:32: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 6D30C21F851A for ; Mon, 15 Aug 2011 00:32:17 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 05ABA23F04C8; Mon, 15 Aug 2011 09:33:02 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 15 Aug 2011 09:33:02 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Mon, 15 Aug 2011 09:33:00 +0200 Thread-Topic: Draft minutes available Thread-Index: AcxSiQdnNkkKVJH9Qoiu6yIIPtjyqAIlHQ/Q Message-ID: Keywords: SIPREC 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 minutes available 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, 15 Aug 2011 07:32:19 -0000 I have received no requests for corrections, so I regard these minutes as c= onfirmed. John =20 > -----Original Message----- > From: Elwell, John=20 > Sent: 04 August 2011 10:30 > To: siprec@ietf.org > Cc: 'Gonzalo Camarillo' > Subject: Draft minutes available >=20 > At: > http://www.ietf.org/proceedings/81/minutes/siprec.txt >=20 > Please let me have any corrections by 2011-08-14. >=20 > John >=20 >=20 > John Elwell > Tel: +44 1908 817801 (office and mobile) > Email: john.elwell@siemens-enterprise.com > http://www.siemens-enterprise.com/uk/ >=20 > Siemens Enterprise Communications Limited. > Registered office: Brickhill Street, Willen Lake, Milton=20 > Keynes, MK15 0DJ. > Registered No: 5903714, England. >=20 > Siemens Enterprise Communications Limited is a Trademark=20 > Licensee of Siemens AG. > = From leon.portman@gmail.com Mon Aug 15 00:43:22 2011 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 52C3B21F8745 for ; Mon, 15 Aug 2011 00:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[AWL=0.848, 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 5pi77zYFTDsG for ; Mon, 15 Aug 2011 00:43:21 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF4C21F8742 for ; Mon, 15 Aug 2011 00:43:21 -0700 (PDT) Received: by vws12 with SMTP id 12so4662454vws.31 for ; Mon, 15 Aug 2011 00:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=8vJhc96AQysvbT9+Nk4RKVtEC8b6SZAqef4A0E34S6g=; b=YVxdta49a+hSUJJcRcALVd+ufjMo+LSLGVPQZz/wEGg9D8xcWdDUlILH0apSDs9FNc uVYMNqJQ716agwluiHjJk71nrjBX9qoESK3RJaDiE/jyBUE2xpbt7A4Wbi1EVCsCo08p 0lTyyQTidWSiR/PnME4eft/C0TQqM2kYtS0m0= MIME-Version: 1.0 Received: by 10.52.89.105 with SMTP id bn9mr3378933vdb.416.1313394246061; Mon, 15 Aug 2011 00:44:06 -0700 (PDT) Received: by 10.220.0.82 with HTTP; Mon, 15 Aug 2011 00:44:06 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Aug 2011 10:44:06 +0300 Message-ID: From: Leon Portman To: "Elwell, John" , "siprec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [siprec] Consensus calls from Quebec 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, 15 Aug 2011 07:43:22 -0000 John Hello Yes, we will send updated draft. Henry already prepared it Leon On 8/15/11, Elwell, John wrote: > I saw no further discussion, so we seem to have consensus on the issues > below. Would the editors please incorporate these changes in > draft-ietf-siprec-metadata-04 and draft-ietf-siprec-protocol-00? > > Thanks, > > John > > >> -----Original Message----- >> From: Elwell, John >> Sent: 04 August 2011 10:32 >> To: siprec@ietf.org >> Subject: Consensus calls from Quebec >> >> The following were agreed at the Quebec face-to-face. Please >> raise any objections by 2011-08-14. >> >> Metadata: >> - Include associate/dissociate times for Participant in a CS. >> - A Participant can exist outside the context of a CS or CSG. >> - Contact header field parameters to be included as an >> attribute of an association between Participant and CS. >> - Multiple identifiers to be allowed for a Participant. >> - Metadata to include information to associate a Participant >> with a CSRC value. >> - All receiving Participants are to be explicitly indicated >> (no receive by default). >> >> Protocol: >> - Proceed with snapshot request to recover from >> synchronization issues (but not syntax errors). >> - Inclusion of sequence number in metadata XML. >> - A snapshot request to lead to repeat of SDP (offer-answer) >> in addition to re-sending of XML. >> - Addition of option tag(s) so that they can be used in >> Require to ensure RS failure if non-compliant UA encountered. >> - Adoption of draft as WG item (note that it will not at this >> stage include RTP text - that will be adopted later). >> >> John >> >> >> >> John Elwell >> Tel: +44 1908 817801 (office and mobile) >> Email: john.elwell@siemens-enterprise.com >> http://www.siemens-enterprise.com/uk/ >> >> Siemens Enterprise Communications Limited. >> Registered office: Brickhill Street, Willen Lake, Milton >> Keynes, MK15 0DJ. >> Registered No: 5903714, England. >> >> Siemens Enterprise Communications Limited is a Trademark >> Licensee of Siemens AG. >> > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > -- Sent from my mobile device From internet-drafts@ietf.org Mon Aug 15 11:55:34 2011 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 3C30811E80CC; Mon, 15 Aug 2011 11:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 XPRaYD0ZkoNe; Mon, 15 Aug 2011 11:55:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E4111E80B8; Mon, 15 Aug 2011 11:55:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.58 Message-ID: <20110815185533.22076.80229.idtracker@ietfa.amsl.com> Date: Mon, 15 Aug 2011 11:55:33 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-protocol-00.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 18:55:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Recording Working Group of the IE= TF. Title : Session Recording Protocol Author(s) : Leon Portman Henry Lum Alan Johnston Andrew Hutton Filename : draft-ietf-siprec-protocol-00.txt Pages : 25 Date : 2011-08-15 The Session Recording Protocol is used for establishing recording session and reporting of the metadata of the communication session. This document specifies the Session Recording Protocol. The protocol is used between Session Recording Client (SRC) and Session Recording Server (SRS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-siprec-protocol-00.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-00.txt From eckelcu@cisco.com Mon Aug 15 14:16:33 2011 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 505CB21F8D28 for ; Mon, 15 Aug 2011 14:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.83 X-Spam-Level: X-Spam-Status: No, score=-2.83 tagged_above=-999 required=5 tests=[AWL=-0.231, 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 vxjXTdTP1vKA for ; Mon, 15 Aug 2011 14:16:32 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 955D321F8D24 for ; Mon, 15 Aug 2011 14:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2372; q=dns/txt; s=iport; t=1313443039; x=1314652639; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=nl1nGrAXVXOMoE6Rzy+YN4NH5dZGfAE2looTT25r9h4=; b=HeVW0hx+7Zg/Gftv/hhyN114xrX7io+9Pyhu1oiNVb0XbGzHAexQAwvq WZn3y6EkBoD/g2xbTglds+NQnyVdBd0oE3rxTb6s7/AWzi/r/SUJr9nMb ktql2ZyBOQCH4z6ZraSr8SRcXJLEikCi7pp9xZOz/e8fVnolkYwpP0oIA k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMAACqMSU6rRDoI/2dsb2JhbABCDpg6j053gUABAQEBAgEBAQEPAR0KNBAHBAIBCA4DBAEBAQoGFwEGASYfCQgBAQQBEggah04EmngBnwaFaF8Eh1+QSIsoWA X-IronPort-AV: E=Sophos;i="4.67,376,1309737600"; d="scan'208";a="13344277" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-5.cisco.com with ESMTP; 15 Aug 2011 21:17:18 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7FLHE5F020445; Mon, 15 Aug 2011 21:17:16 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Aug 2011 14:17:15 -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, 15 Aug 2011 14:17:14 -0700 Message-ID: In-Reply-To: <4E3AABCD.4010603@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] associate a Participant with a CSRC value Thread-Index: AcxSsmFWQBe7joTNTDCfJvWjGE/N3gI3R0qw References: <4E3AABCD.4010603@alum.mit.edu> From: "Charles Eckel (eckelcu)" To: "Paul Kyzivat" , X-OriginalArrivalTime: 15 Aug 2011 21:17:15.0244 (UTC) FILETIME=[B4BA7AC0:01CC5B90] Subject: Re: [siprec] associate a Participant with a CSRC value 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, 15 Aug 2011 21:16:33 -0000 Hi Paul, Sorry for the late response. Please see comments inline. > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Thursday, August 04, 2011 7:25 AM > To: siprec@ietf.org > Subject: Re: [siprec] associate a Participant with a CSRC value >=20 > On 8/4/11 5:31 AM, Elwell, John wrote: > > The following were agreed at the Quebec face-to-face. Please raise any objections by 2011-08-14. >=20 > > - Metadata to include information to associate a Participant with a CSRC value. >=20 > I'd like to double check with those who know RTP better than I: >=20 > I *presume* that CSRC assignments may be made on a per-media stream > basis, and so the association of Participant to CSRC must be specified > separately for each stream. It is really more the SSRC assignment that we needed, and yes, there may be more than 1. The SSRCs becomes the CSRCs when a mixer combines multiple contributing sources into a single mixed stream. In this case the SSRC is that of the mixer, and the CSRCs are the SSRCs of the original streams combined by the mixer.=20 The SSRC can change due to collisions of SSRC values, and multiple SSRCS may be used to multiplex multiple streams within a single RTP session. > So, a participant may have multiple CSRCs - potentially a different one > for each stream in which it participates. Yes, but really multiple SSRCs, which may result in multiple CSRCs. =20 > And IIUC the CSRC value representing a participant can change over time > within a stream. Yes. =20 > I think it may also be the case that one CSRC value may represent > different participants in different streams, though its my impression > this would be rare. I guess is a mixer is mixing previously mixed streams, this could happen; but really the first mixer should preserve the original SRCSs as CSRCs in the stream it sends, and the second mixer should preserve these CSRCs as CSRCs in the stream it sends. =20 Cheers, Charles > Does anyone disagree with the above? >=20 > And a question: can a single participant have multiple CSRCs > concurrently for the same stream? >=20 > Thanks, > Paul > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Tue Aug 16 13:25:29 2011 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 03E8C11E808F for ; Tue, 16 Aug 2011 13:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.359 X-Spam-Level: X-Spam-Status: No, score=-103.359 tagged_above=-999 required=5 tests=[AWL=-0.760, 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 jm+c3mJvjPBu for ; Tue, 16 Aug 2011 13:25:28 -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 5F78A11E807F for ; Tue, 16 Aug 2011 13:25:28 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id E89911EB8492 for ; Tue, 16 Aug 2011 22:26:15 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 16 Aug 2011 22:26:16 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Tue, 16 Aug 2011 22:26:14 +0200 Thread-Topic: Draft-ietf-siprec-protocol diff Thread-Index: AcxcUr6otiCXm5W9Ra+VgElHMj3T/g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Draft-ietf-siprec-protocol diff 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, 16 Aug 2011 20:25:29 -0000 The new protocol draft posted a couple of days ago replaces the former draf= t-portman-siprec-protocol. This is now shown on the datatracker, allowing a= diff to be obtained easily: https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol/history/ John= From john.elwell@siemens-enterprise.com Thu Aug 18 03:33:52 2011 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 4D97821F893C for ; Thu, 18 Aug 2011 03:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.338 X-Spam-Level: X-Spam-Status: No, score=-103.338 tagged_above=-999 required=5 tests=[AWL=-0.739, 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 vJ+h0J6sPlnO for ; Thu, 18 Aug 2011 03:33:51 -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 D6E3C21F8839 for ; Thu, 18 Aug 2011 03:33:50 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 1484023F0412; Thu, 18 Aug 2011 12:34:44 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 18 Aug 2011 12:34:44 +0200 From: "Elwell, John" To: "Charles Eckel (eckelcu)" , Leon Portman , Paul Kyzivat Date: Thu, 18 Aug 2011 12:34:42 +0200 Thread-Topic: [siprec] Do we need a stream element? Thread-Index: AcxV+dLX3pDIVhzSSHiFe6d7TlcwhQBa4/SwADW3PdABVWOBEA== Message-ID: References: <4E3BFC29.6050001@alum.mit.edu><4E402C2F.1080103@alum.mit.edu> <07465C1D981ABC41A344374066AE1A2C38B0304DA2@TLVMBX01.nice.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Do we need a stream element? 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, 18 Aug 2011 10:33:52 -0000 =20 > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]=20 > Sent: 11 August 2011 16:44 > To: Leon Portman; Paul Kyzivat; Elwell, John > Cc: siprec@ietf.org > Subject: RE: [siprec] Do we need a stream element? >=20 > The media stream element was more intuitive to me when I understood it > to describe the CS media streams. Now that I understand it to=20 > be the RS > media streams, I agree with John that the SDP could be sufficient. > I believe I understand the points Paul and Leon are making=20 > with respect > to long duration recordings; however, it does seem to me that we now > have multiple mechanisms to describe very similar information (RS SDP, > RS media stream, send/recv elements). I would prefer to eliminate some > of the redundancy, otherwise I fear we will create duplications, and > even worse, inconsistencies.=20 [JRE] Yes, that was basically my concern - redundant information and/or too= many ways to accomplish the same thing. John (as individual) >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Leon Portman > > Sent: Wednesday, August 10, 2011 6:58 AM > > To: Paul Kyzivat; Elwell, John > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Do we need a stream element? > >=20 > > I also think it will be cleaner to have dedicated MS element. We can > think about scenarios where it > > can be "reused" by different participants. > >=20 > > Leon > >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > > Sent: Monday, August 08, 2011 9:34 PM > > To: Elwell, John > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Do we need a stream element? > >=20 > > On 8/8/11 4:08 AM, Elwell, John wrote: > > > > > > > > >> -----Original Message----- > > >> From: siprec-bounces@ietf.org > > >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > >> Sent: 05 August 2011 15:20 > > >> To: siprec@ietf.org > > >> Subject: Re: [siprec] Do we need a stream element? > > >> > > >> John, > > >> > > >> On 8/5/11 5:03 AM, Elwell, John wrote: > > >>> (as individual) > > >>> > > >>> Do we need a stream element in the XML? In Quebec we said > > >> start and stop times should be tied to the association between > > >> participant and stream, not to the stream itself. > > >> This seems to suggest they be part of the send and recv > sub-elements > > >> of a participant element. The mode element also seems not to be > > >> needed, since mixed or separate can be deduced from other > > >> information. The only relevant information seems to be the label. > > >>> > > >>> So it seems to be a waste of space for send and recv > > >> sub-elements of a participant element to contain a unique ID > pointing > > >> to a stream element that then just contains a label. > > >> Why don't the send and recv elements simply contain the=20 > label (plus > > >> start and stop times, to meet what was decided in Quebec)? > > >>> > > >>> In other words, the MediaStream element in the model is > > >> entirely represented by a media description in SDP. > > >> > > >> I think your point here is that the stream "class" will=20 > still exist > > >> in the model, but its conveyed entirely in SDP and thus does not > need > > >> an xml representation. > > >> > > >> One thing the xml element provides is a way to assign a true > globally > > >> unique id, which allows the same stream to be referenced from > > >> multiple recording sessions. Until now, we have not stated that > > >> labels are unique ids. Rather, we have said (at least informally) > > >> that the labels are transient, used to bind the stream xml to the > SDP > > >> within a single message. > > > [JRE] From past discussions, I am led to believe that a stream > element represents an RS stream, and > > therefore the idea of having a unique ID that works from=20 > different RSs > doesn't seem relevant. > >=20 > > I suspect maybe we are still not all on the same page about this. > >=20 > > Lets consider the case of a UA that is its own SRC. I pick that case > > simply because it is then plausible that it knows a fair=20 > amount about > > the things it is recording. > >=20 > > For instance, it might be an office phone, P, in an office=20 > that gets a > > lot of calls and wants to record them all. It could=20 > establish an RS at > > the beginning of the day, and use it for all calls in which it is > involved. > >=20 > > Assume P makes a voice call to A. Then after that=20 > completes, P gets a > > call from B, and that completes. > >=20 > > If P does its own mixing, then it needs only a single=20 > m-line in the RS > > to accomplish this, using if first for the call with A and then for > the > > call with B. > >=20 > > The question is whether that is one MS object, or two. > >=20 > > There will be two session elements, one for each call. Each=20 > will refer > > to one MS element - either the same one, or a different=20 > one. If its a > > single one, then for the duration of the first call the participants > of > > the MS will be P and A, while during the 2nd call the participants > will > > be P & B. Is that enough for the SRS to understand what is going on? > >=20 > > It gets more complex of the two calls are overlapped in=20 > time. Perhaps > > the call from B comes before the call with A is over. So P puts A on > > hold, answers and completes the call with B and then=20 > resumes the call > > with A. > >=20 > > In that case, if there is no MoH, P may still need only a single > m-line > > in the RS to handle this. Then, the participants for the only MS are > > first P&A, then P&B, then P&A. The MS would then need to be switched > > from the first session, to the second, and back to the first. > >=20 > > I think this *can* work either way, and is to some extent a=20 > matter of > > taste. But it has to be carefully documented one way or the=20 > other. In > > *my* mind having separate MS objects makes sense, but maybe that is > just > > a bias on my part. > >=20 > > Thanks, > > Paul > >=20 > >=20 > > >> I suppose we *could* specify a UUID representation that can > > >> be used as a > > >> label in SDP. (That is possible, but would have to be an > > >> unusual radix64 > > >> representation, or we could use hex.) > > >> > > >> I'm a bit reluctant to go this way because it eliminates the > > >> opportunity > > >> to associate other data with a stream, including extension data. > But > > >> lets discuss it further. > > > [JRE] I see your point, but would such extension data be more > appropriate as part of a send or recv > > element? > >=20 > > I think either place could make sense, but for different things. > > If you have data about why the sending is taking place or what it is > > about, then that belongs on the element. If you have data on > why > > the stream as a whole exists, regardless of sender, then=20 > extending the > > MS makes more sense. (But if the MS merely represents the m-line in > the > > RS, then metadata on it probably doesn't make much sense.) > >=20 > > Thanks > > Paul > >=20 > >=20 > > > John Elwell > > > Tel: +44 1908 817801 (office and mobile) > > > Email: john.elwell@siemens-enterprise.com > > > http://www.siemens-enterprise.com/uk/ > > > > > > Siemens Enterprise Communications Limited. > > > Registered office: Brickhill Street, Willen Lake, Milton Keynes, > MK15 0DJ. > > > Registered No: 5903714, England. > > > > > > Siemens Enterprise Communications Limited is a Trademark=20 > Licensee of > Siemens AG. > > > > > > > > >> > > >> Thanks, > > >> Paul > > >> > > >>> For example, the schema might look something like this: > > >>> > > >>> > >>> minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > >>> > >>> minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > >>> > > >>> > > >>> > > >>> > >>> minOccurs=3D"0" maxOccurs=3D"1"/> > > >>> > >>> minOccurs=3D"0"/> > > >>> > >>> minOccurs=3D"0"/> > > >>> > >>> minOccurs=3D"0"/> > > >>> > > >>> > > >>> > > >>> John > > >>> _______________________________________________ > > >>> siprec mailing list > > >>> siprec@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/siprec > > >>> > > >> > > >> _______________________________________________ > > >> siprec mailing list > > >> siprec@ietf.org > > >> https://www.ietf.org/mailman/listinfo/siprec > > >> > >=20 > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > = From john.elwell@siemens-enterprise.com Thu Aug 18 03:47:06 2011 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 5F9BE21F8571 for ; Thu, 18 Aug 2011 03:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.331 X-Spam-Level: X-Spam-Status: No, score=-103.331 tagged_above=-999 required=5 tests=[AWL=-0.733, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, 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 PTaEAWf66J-Q for ; Thu, 18 Aug 2011 03:47:05 -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 1CB6E21F85B9 for ; Thu, 18 Aug 2011 03:47:05 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 0C2341EB8444; Thu, 18 Aug 2011 12:47:56 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 18 Aug 2011 12:47:56 +0200 From: "Elwell, John" To: Ofir Roth , "siprec@ietf.org" Date: Thu, 18 Aug 2011 12:47:55 +0200 Thread-Topic: [siprec] Metadata schema - missing group element in element recording Thread-Index: AcxXTJquqGjtR5XATL25Utt2WXBOjAGRz7Ww Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Metadata schema - missing group element in element 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, 18 Aug 2011 10:47:06 -0000 Ofir, Yes, there certainly seems to be an issue here, because there doesn't seem = to be any place in the schema that a group element can appear. According to= the example in 7.1 it can appear in the recording element, as you suggest.= So can the metadata authors please attend to this? John John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Ofir Roth > Sent: 10 August 2011 12:00 > To: siprec@ietf.org > Subject: [siprec] Metadata schema - missing group element in=20 > element recording >=20 > Hi, >=20 > =20 >=20 > My name is Ofir and I am a software developer in NICE Systems.=20 > I have reviewed the XML schema defining the metadata=20 > (http://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/?i > nclude_text=3D1) and noticed that "group" element is missing=20 > from the sequence of "recording" element. It is defined as a=20 > standalone element but should also be embedded in the=20 > recording element. >=20 > =20 >=20 > >=20 > >=20 > =20 > minOccurs=3D"0"/> >=20 > =20 > minOccurs=3D"0" maxOccurs=3D"unbounded"/> >=20 > =20 > minOccurs=3D"0" maxOccurs=3D"unbounded"/> >=20 > =20 > minOccurs=3D"0" maxOccurs=3D"unbounded"/> >=20 > =20 > minOccurs=3D"0" maxOccurs=3D"unbounded"/> >=20 > >=20 > >=20 > =20 >=20 > Please advise. >=20 > =20 >=20 > Thanks, >=20 > Ofir. >=20 > =20 >=20 > = From pravindran@sonusnet.com Thu Aug 18 04:34:52 2011 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 7B87021F877B for ; Thu, 18 Aug 2011 04:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFvF34ISEG6x for ; Thu, 18 Aug 2011 04:34:51 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6D21B21F8779 for ; Thu, 18 Aug 2011 04:34:51 -0700 (PDT) Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p7IBaAIK001811; Thu, 18 Aug 2011 07:36:10 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Aug 2011 07:35:42 -0400 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, 18 Aug 2011 17:05:38 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51064019@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Metadata schema - missing group element in element recording Thread-Index: AcxXTJquqGjtR5XATL25Utt2WXBOjAGRz7WwAAGUAMA= References: From: "Ravindran Parthasarathi" To: "Elwell, John" , "Ofir Roth" , X-OriginalArrivalTime: 18 Aug 2011 11:35:42.0864 (UTC) FILETIME=[F67D1100:01CC5D9A] Subject: Re: [siprec] Metadata schema - missing group element in element 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, 18 Aug 2011 11:34:52 -0000 Ofir/John, Thanks for your comment. As you expect, XML schema has to be enhanced to include group element in recording element. Metadata example is given correctly but not XML schema. We will update in the next revision.=20 Thanks Partha > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Thursday, August 18, 2011 4:18 PM > To: Ofir Roth; siprec@ietf.org > Subject: Re: [siprec] Metadata schema - missing group element inelement > recording >=20 > Ofir, >=20 > Yes, there certainly seems to be an issue here, because there doesn't > seem to be any place in the schema that a group element can appear. > According to the example in 7.1 it can appear in the recording element, > as you suggest. So can the metadata authors please attend to this? >=20 > John >=20 > John Elwell > Tel: +44 1908 817801 (office and mobile) > Email: john.elwell@siemens-enterprise.com > http://www.siemens-enterprise.com/uk/ >=20 > Siemens Enterprise Communications Limited. > Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 > 0DJ. > Registered No: 5903714, England. >=20 > Siemens Enterprise Communications Limited is a Trademark Licensee of > Siemens AG. >=20 >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Ofir Roth > > Sent: 10 August 2011 12:00 > > To: siprec@ietf.org > > Subject: [siprec] Metadata schema - missing group element in > > element recording > > > > Hi, > > > > > > > > My name is Ofir and I am a software developer in NICE Systems. > > I have reviewed the XML schema defining the metadata > > (http://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/?i > > nclude_text=3D1) and noticed that "group" element is missing > > from the sequence of "recording" element. It is defined as a > > standalone element but should also be embedded in the > > recording element. > > > > > > > > > > > > > > > > > > > minOccurs=3D"0"/> > > > > > > > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > > > > > > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > > > > > > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > > > > > > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > > > > > > > > > > > > > > > Please advise. > > > > > > > > Thanks, > > > > Ofir. > > > > > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pravindran@sonusnet.com Fri Aug 19 10:42:45 2011 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 C314921F86B6 for ; Fri, 19 Aug 2011 10:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_22=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 UCcL4geD6jpK for ; Fri, 19 Aug 2011 10:42:44 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6A47A21F8A62 for ; Fri, 19 Aug 2011 10:42:44 -0700 (PDT) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p7JHi66a014726; Fri, 19 Aug 2011 13:44:06 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Aug 2011 13:42:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Aug 2011 23:12:27 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510640D1@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Do we need a stream element? Thread-Index: AcxV+dLX3pDIVhzSSHiFe6d7TlcwhQBa4/SwADW3PdABVWOBEABAqGaA References: <4E3BFC29.6050001@alum.mit.edu><4E402C2F.1080103@alum.mit.edu><07465C1D981ABC41A344374066AE1A2C38B0304DA2@TLVMBX01.nice.com> From: "Ravindran Parthasarathi" To: "Elwell, John" , "Charles Eckel (eckelcu)" , "Leon Portman" , "Paul Kyzivat" X-OriginalArrivalTime: 19 Aug 2011 17:42:45.0661 (UTC) FILETIME=[6782F4D0:01CC5E97] Cc: siprec@ietf.org Subject: Re: [siprec] Do we need a stream element? 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, 19 Aug 2011 17:42:45 -0000 I remember that we have discussed during one of the interim before IETF-81 for the need of (Media) stream global-id which is different from label attribute in SDP. In case of RS to CS for 1:1 mapping, stream element and its global id looks overhead which I agree with John.=20 I could recollect two of the scenario wherein stream element is useful: Scenario 1: CS:RS is in 1:N with multiple m-lines and unmixed stream to SRS. Here there is a need to map single stream with different RS SDP consistently using a unique id wherein stream global id shall be used. Few examples are=20 A ) Typical call center scenario wherein single customer call is transferred to multiple agents in the single session. B) Start/Stop of CS which results in multiple RS. Scenario 2: Multicast scenario (Ram mentioned in another mail thread) In case better way to solve the above scenario, Please let us discuss about it. Thanks Partha > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Thursday, August 18, 2011 4:05 PM > To: Charles Eckel (eckelcu); Leon Portman; Paul Kyzivat > Cc: siprec@ietf.org > Subject: Re: [siprec] Do we need a stream element? >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > Sent: 11 August 2011 16:44 > > To: Leon Portman; Paul Kyzivat; Elwell, John > > Cc: siprec@ietf.org > > Subject: RE: [siprec] Do we need a stream element? > > > > The media stream element was more intuitive to me when I understood > it > > to describe the CS media streams. Now that I understand it to > > be the RS > > media streams, I agree with John that the SDP could be sufficient. > > I believe I understand the points Paul and Leon are making > > with respect > > to long duration recordings; however, it does seem to me that we now > > have multiple mechanisms to describe very similar information (RS > SDP, > > RS media stream, send/recv elements). I would prefer to eliminate > some > > of the redundancy, otherwise I fear we will create duplications, and > > even worse, inconsistencies. > [JRE] Yes, that was basically my concern - redundant information and/or > too many ways to accomplish the same thing. >=20 > John (as individual) >=20 >=20 > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Leon Portman > > > Sent: Wednesday, August 10, 2011 6:58 AM > > > To: Paul Kyzivat; Elwell, John > > > Cc: siprec@ietf.org > > > Subject: Re: [siprec] Do we need a stream element? > > > > > > I also think it will be cleaner to have dedicated MS element. We > can > > think about scenarios where it > > > can be "reused" by different participants. > > > > > > Leon > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > > Sent: Monday, August 08, 2011 9:34 PM > > > To: Elwell, John > > > Cc: siprec@ietf.org > > > Subject: Re: [siprec] Do we need a stream element? > > > > > > On 8/8/11 4:08 AM, Elwell, John wrote: > > > > > > > > > > > >> -----Original Message----- > > > >> From: siprec-bounces@ietf.org > > > >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > > >> Sent: 05 August 2011 15:20 > > > >> To: siprec@ietf.org > > > >> Subject: Re: [siprec] Do we need a stream element? > > > >> > > > >> John, > > > >> > > > >> On 8/5/11 5:03 AM, Elwell, John wrote: > > > >>> (as individual) > > > >>> > > > >>> Do we need a stream element in the XML? In Quebec we said > > > >> start and stop times should be tied to the association between > > > >> participant and stream, not to the stream itself. > > > >> This seems to suggest they be part of the send and recv > > sub-elements > > > >> of a participant element. The mode element also seems not to be > > > >> needed, since mixed or separate can be deduced from other > > > >> information. The only relevant information seems to be the > label. > > > >>> > > > >>> So it seems to be a waste of space for send and recv > > > >> sub-elements of a participant element to contain a unique ID > > pointing > > > >> to a stream element that then just contains a label. > > > >> Why don't the send and recv elements simply contain the > > label (plus > > > >> start and stop times, to meet what was decided in Quebec)? > > > >>> > > > >>> In other words, the MediaStream element in the model is > > > >> entirely represented by a media description in SDP. > > > >> > > > >> I think your point here is that the stream "class" will > > still exist > > > >> in the model, but its conveyed entirely in SDP and thus does not > > need > > > >> an xml representation. > > > >> > > > >> One thing the xml element provides is a way to assign a true > > globally > > > >> unique id, which allows the same stream to be referenced from > > > >> multiple recording sessions. Until now, we have not stated that > > > >> labels are unique ids. Rather, we have said (at least > informally) > > > >> that the labels are transient, used to bind the stream xml to > the > > SDP > > > >> within a single message. > > > > [JRE] From past discussions, I am led to believe that a stream > > element represents an RS stream, and > > > therefore the idea of having a unique ID that works from > > different RSs > > doesn't seem relevant. > > > > > > I suspect maybe we are still not all on the same page about this. > > > > > > Lets consider the case of a UA that is its own SRC. I pick that > case > > > simply because it is then plausible that it knows a fair > > amount about > > > the things it is recording. > > > > > > For instance, it might be an office phone, P, in an office > > that gets a > > > lot of calls and wants to record them all. It could > > establish an RS at > > > the beginning of the day, and use it for all calls in which it is > > involved. > > > > > > Assume P makes a voice call to A. Then after that > > completes, P gets a > > > call from B, and that completes. > > > > > > If P does its own mixing, then it needs only a single > > m-line in the RS > > > to accomplish this, using if first for the call with A and then for > > the > > > call with B. > > > > > > The question is whether that is one MS object, or two. > > > > > > There will be two session elements, one for each call. Each > > will refer > > > to one MS element - either the same one, or a different > > one. If its a > > > single one, then for the duration of the first call the > participants > > of > > > the MS will be P and A, while during the 2nd call the participants > > will > > > be P & B. Is that enough for the SRS to understand what is going > on? > > > > > > It gets more complex of the two calls are overlapped in > > time. Perhaps > > > the call from B comes before the call with A is over. So P puts A > on > > > hold, answers and completes the call with B and then > > resumes the call > > > with A. > > > > > > In that case, if there is no MoH, P may still need only a single > > m-line > > > in the RS to handle this. Then, the participants for the only MS > are > > > first P&A, then P&B, then P&A. The MS would then need to be > switched > > > from the first session, to the second, and back to the first. > > > > > > I think this *can* work either way, and is to some extent a > > matter of > > > taste. But it has to be carefully documented one way or the > > other. In > > > *my* mind having separate MS objects makes sense, but maybe that is > > just > > > a bias on my part. > > > > > > Thanks, > > > Paul > > > > > > > > > >> I suppose we *could* specify a UUID representation that can > > > >> be used as a > > > >> label in SDP. (That is possible, but would have to be an > > > >> unusual radix64 > > > >> representation, or we could use hex.) > > > >> > > > >> I'm a bit reluctant to go this way because it eliminates the > > > >> opportunity > > > >> to associate other data with a stream, including extension data. > > But > > > >> lets discuss it further. > > > > [JRE] I see your point, but would such extension data be more > > appropriate as part of a send or recv > > > element? > > > > > > I think either place could make sense, but for different things. > > > If you have data about why the sending is taking place or what it > is > > > about, then that belongs on the element. If you have data on > > why > > > the stream as a whole exists, regardless of sender, then > > extending the > > > MS makes more sense. (But if the MS merely represents the m-line in > > the > > > RS, then metadata on it probably doesn't make much sense.) > > > > > > Thanks > > > Paul > > > > > > > > > > John Elwell > > > > Tel: +44 1908 817801 (office and mobile) > > > > Email: john.elwell@siemens-enterprise.com > > > > http://www.siemens-enterprise.com/uk/ > > > > > > > > Siemens Enterprise Communications Limited. > > > > Registered office: Brickhill Street, Willen Lake, Milton Keynes, > > MK15 0DJ. > > > > Registered No: 5903714, England. > > > > > > > > Siemens Enterprise Communications Limited is a Trademark > > Licensee of > > Siemens AG. > > > > > > > > > > > >> > > > >> Thanks, > > > >> Paul > > > >> > > > >>> For example, the schema might look something like this: > > > >>> > > > >>> > > >>> minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > > >>> > > >>> minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > > >>> > > > >>> > > > >>> > > > >>> > > >>> minOccurs=3D"0" maxOccurs=3D"1"/> > > > >>> > > >>> minOccurs=3D"0"/> > > > >>> > > >>> minOccurs=3D"0"/> > > > >>> > > >>> minOccurs=3D"0"/> > > > >>> > > > >>> > > > >>> > > > >>> John > > > >>> _______________________________________________ > > > >>> siprec mailing list > > > >>> siprec@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/siprec > > > >>> > > > >> > > > >> _______________________________________________ > > > >> siprec mailing list > > > >> siprec@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/siprec > > > >> > > > > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Mon Aug 22 00:07:40 2011 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 D5CA821F8829 for ; Mon, 22 Aug 2011 00:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.978, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, 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 igI1L61vyKZz for ; Mon, 22 Aug 2011 00:07:39 -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 3AB1821F86B1 for ; Mon, 22 Aug 2011 00:07:36 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 48CB723F0462; Mon, 22 Aug 2011 09:08:39 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 22 Aug 2011 09:08:39 +0200 From: "Elwell, John" To: Ravindran Parthasarathi , "Charles Eckel (eckelcu)" , Leon Portman , Paul Kyzivat Date: Mon, 22 Aug 2011 09:08:36 +0200 Thread-Topic: [siprec] Do we need a stream element? Thread-Index: AcxV+dLX3pDIVhzSSHiFe6d7TlcwhQBa4/SwADW3PdABVWOBEABAqGaAAIBSOpA= Message-ID: References: <4E3BFC29.6050001@alum.mit.edu><4E402C2F.1080103@alum.mit.edu><07465C1D981ABC41A344374066AE1A2C38B0304DA2@TLVMBX01.nice.com> <2E239D6FCD033C4BAF15F386A979BF510640D1@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510640D1@sonusinmail02.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Do we need a stream element? 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, 22 Aug 2011 07:07:40 -0000 Partha,=20 Of course, we agreed an MS would have a unique identifier (June interim mee= ting), but what has emerged since then is that the unique identifier seems = to be the only attribute needed for MS, which led me to doubt the need for = the element in XML - just reference the SDP media description from particip= ant send/recv elements. Having an explicit MS element with unique identifie= r seems to be a significant overhead for simple usages just to accommodate = these more complex usages. I don't particularly want to re-open the old iss= ue, but it concerns me that we don't have a clear definition of a MediaStre= am object. I can't find one in draft-03, It seems it represents neither a C= S media stream (because some people insisted that a media stream can, under= some circumstances, have a lifetime outside a single CS), nor an RS media = stream (because of the arguments you make below). So what is it exactly? Pl= ease can somebody propose a clear and concise definition of a MediaStream o= bject? John (as individual) > -----Original Message----- > From: Ravindran Parthasarathi [mailto:pravindran@sonusnet.com]=20 > Sent: 19 August 2011 18:42 > To: Elwell, John; Charles Eckel (eckelcu); Leon Portman; Paul Kyzivat > Cc: siprec@ietf.org > Subject: RE: [siprec] Do we need a stream element? >=20 > I remember that we have discussed during one of the interim before > IETF-81 for the need of (Media) stream global-id which is=20 > different from > label attribute in SDP. In case of RS to CS for 1:1 mapping, stream > element and its global id looks overhead which I agree with John.=20 >=20 > I could recollect two of the scenario wherein stream element=20 > is useful: >=20 > Scenario 1: CS:RS is in 1:N with multiple m-lines and unmixed=20 > stream to > SRS. Here there is a need to map single stream with different RS SDP > consistently using a unique id wherein stream global id shall be used. > Few examples are=20 > A ) Typical call center scenario wherein single customer call is > transferred to multiple agents in the single session. > B) Start/Stop of CS which results in multiple RS. >=20 > Scenario 2: Multicast scenario (Ram mentioned in another mail thread) >=20 > In case better way to solve the above scenario, Please let us discuss > about it. >=20 > Thanks > Partha >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > > Sent: Thursday, August 18, 2011 4:05 PM > > To: Charles Eckel (eckelcu); Leon Portman; Paul Kyzivat > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Do we need a stream element? > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > Sent: 11 August 2011 16:44 > > > To: Leon Portman; Paul Kyzivat; Elwell, John > > > Cc: siprec@ietf.org > > > Subject: RE: [siprec] Do we need a stream element? > > > > > > The media stream element was more intuitive to me when I=20 > understood > > it > > > to describe the CS media streams. Now that I understand it to > > > be the RS > > > media streams, I agree with John that the SDP could be sufficient. > > > I believe I understand the points Paul and Leon are making > > > with respect > > > to long duration recordings; however, it does seem to me=20 > that we now > > > have multiple mechanisms to describe very similar information (RS > > SDP, > > > RS media stream, send/recv elements). I would prefer to eliminate > > some > > > of the redundancy, otherwise I fear we will create=20 > duplications, and > > > even worse, inconsistencies. > > [JRE] Yes, that was basically my concern - redundant information > and/or > > too many ways to accomplish the same thing. > >=20 > > John (as individual) > >=20 > >=20 > > > > > > Cheers, > > > Charles > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Leon Portman > > > > Sent: Wednesday, August 10, 2011 6:58 AM > > > > To: Paul Kyzivat; Elwell, John > > > > Cc: siprec@ietf.org > > > > Subject: Re: [siprec] Do we need a stream element? > > > > > > > > I also think it will be cleaner to have dedicated MS element. We > > can > > > think about scenarios where it > > > > can be "reused" by different participants. > > > > > > > > Leon > > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Paul Kyzivat > > > > Sent: Monday, August 08, 2011 9:34 PM > > > > To: Elwell, John > > > > Cc: siprec@ietf.org > > > > Subject: Re: [siprec] Do we need a stream element? > > > > > > > > On 8/8/11 4:08 AM, Elwell, John wrote: > > > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: siprec-bounces@ietf.org > > > > >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > > > >> Sent: 05 August 2011 15:20 > > > > >> To: siprec@ietf.org > > > > >> Subject: Re: [siprec] Do we need a stream element? > > > > >> > > > > >> John, > > > > >> > > > > >> On 8/5/11 5:03 AM, Elwell, John wrote: > > > > >>> (as individual) > > > > >>> > > > > >>> Do we need a stream element in the XML? In Quebec we said > > > > >> start and stop times should be tied to the=20 > association between > > > > >> participant and stream, not to the stream itself. > > > > >> This seems to suggest they be part of the send and recv > > > sub-elements > > > > >> of a participant element. The mode element also=20 > seems not to be > > > > >> needed, since mixed or separate can be deduced from other > > > > >> information. The only relevant information seems to be the > > label. > > > > >>> > > > > >>> So it seems to be a waste of space for send and recv > > > > >> sub-elements of a participant element to contain a unique ID > > > pointing > > > > >> to a stream element that then just contains a label. > > > > >> Why don't the send and recv elements simply contain the > > > label (plus > > > > >> start and stop times, to meet what was decided in Quebec)? > > > > >>> > > > > >>> In other words, the MediaStream element in the model is > > > > >> entirely represented by a media description in SDP. > > > > >> > > > > >> I think your point here is that the stream "class" will > > > still exist > > > > >> in the model, but its conveyed entirely in SDP and thus does > not > > > need > > > > >> an xml representation. > > > > >> > > > > >> One thing the xml element provides is a way to assign a true > > > globally > > > > >> unique id, which allows the same stream to be referenced from > > > > >> multiple recording sessions. Until now, we have not=20 > stated that > > > > >> labels are unique ids. Rather, we have said (at least > > informally) > > > > >> that the labels are transient, used to bind the stream xml to > > the > > > SDP > > > > >> within a single message. > > > > > [JRE] From past discussions, I am led to believe that a stream > > > element represents an RS stream, and > > > > therefore the idea of having a unique ID that works from > > > different RSs > > > doesn't seem relevant. > > > > > > > > I suspect maybe we are still not all on the same page=20 > about this. > > > > > > > > Lets consider the case of a UA that is its own SRC. I pick that > > case > > > > simply because it is then plausible that it knows a fair > > > amount about > > > > the things it is recording. > > > > > > > > For instance, it might be an office phone, P, in an office > > > that gets a > > > > lot of calls and wants to record them all. It could > > > establish an RS at > > > > the beginning of the day, and use it for all calls in=20 > which it is > > > involved. > > > > > > > > Assume P makes a voice call to A. Then after that > > > completes, P gets a > > > > call from B, and that completes. > > > > > > > > If P does its own mixing, then it needs only a single > > > m-line in the RS > > > > to accomplish this, using if first for the call with A and then > for > > > the > > > > call with B. > > > > > > > > The question is whether that is one MS object, or two. > > > > > > > > There will be two session elements, one for each call. Each > > > will refer > > > > to one MS element - either the same one, or a different > > > one. If its a > > > > single one, then for the duration of the first call the > > participants > > > of > > > > the MS will be P and A, while during the 2nd call the=20 > participants > > > will > > > > be P & B. Is that enough for the SRS to understand what is going > > on? > > > > > > > > It gets more complex of the two calls are overlapped in > > > time. Perhaps > > > > the call from B comes before the call with A is over.=20 > So P puts A > > on > > > > hold, answers and completes the call with B and then > > > resumes the call > > > > with A. > > > > > > > > In that case, if there is no MoH, P may still need only a single > > > m-line > > > > in the RS to handle this. Then, the participants for the only MS > > are > > > > first P&A, then P&B, then P&A. The MS would then need to be > > switched > > > > from the first session, to the second, and back to the first. > > > > > > > > I think this *can* work either way, and is to some extent a > > > matter of > > > > taste. But it has to be carefully documented one way or the > > > other. In > > > > *my* mind having separate MS objects makes sense, but maybe that > is > > > just > > > > a bias on my part. > > > > > > > > Thanks, > > > > Paul > > > > > > > > > > > > >> I suppose we *could* specify a UUID representation that can > > > > >> be used as a > > > > >> label in SDP. (That is possible, but would have to be an > > > > >> unusual radix64 > > > > >> representation, or we could use hex.) > > > > >> > > > > >> I'm a bit reluctant to go this way because it eliminates the > > > > >> opportunity > > > > >> to associate other data with a stream, including extension > data. > > > But > > > > >> lets discuss it further. > > > > > [JRE] I see your point, but would such extension data be more > > > appropriate as part of a send or recv > > > > element? > > > > > > > > I think either place could make sense, but for different things. > > > > If you have data about why the sending is taking place=20 > or what it > > is > > > > about, then that belongs on the element. If you have data > on > > > why > > > > the stream as a whole exists, regardless of sender, then > > > extending the > > > > MS makes more sense. (But if the MS merely represents the m-line > in > > > the > > > > RS, then metadata on it probably doesn't make much sense.) > > > > > > > > Thanks > > > > Paul > > > > > > > > > > > > > John Elwell > > > > > Tel: +44 1908 817801 (office and mobile) > > > > > Email: john.elwell@siemens-enterprise.com > > > > > http://www.siemens-enterprise.com/uk/ > > > > > > > > > > Siemens Enterprise Communications Limited. > > > > > Registered office: Brickhill Street, Willen Lake,=20 > Milton Keynes, > > > MK15 0DJ. > > > > > Registered No: 5903714, England. > > > > > > > > > > Siemens Enterprise Communications Limited is a Trademark > > > Licensee of > > > Siemens AG. > > > > > > > > > > > > > > >> > > > > >> Thanks, > > > > >> Paul > > > > >> > > > > >>> For example, the schema might look something like this: > > > > >>> > > > > >>> > > > >>> minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > > > >>> > > > >>> minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > >>> minOccurs=3D"0" maxOccurs=3D"1"/> > > > > >>> > > > >>> minOccurs=3D"0"/> > > > > >>> > > > >>> minOccurs=3D"0"/> > > > > >>> > > > >>> minOccurs=3D"0"/> > > > > >>> > > > > >>> > > > > >>> > > > > >>> John > > > > >>> _______________________________________________ > > > > >>> siprec mailing list > > > > >>> siprec@ietf.org > > > > >>> https://www.ietf.org/mailman/listinfo/siprec > > > > >>> > > > > >> > > > > >> _______________________________________________ > > > > >> siprec mailing list > > > > >> siprec@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/siprec > > > > >> > > > > > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > = From pkyzivat@alum.mit.edu Mon Aug 22 06:50:04 2011 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 30FF621F8B48 for ; Mon, 22 Aug 2011 06:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, J_CHICKENPOX_22=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 mAvkZ+Xw7I3L for ; Mon, 22 Aug 2011 06:50:03 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id B1D9221F8B47 for ; Mon, 22 Aug 2011 06:50:02 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta14.westchester.pa.mail.comcast.net with comcast id PRmX1h00B1swQuc5ERr8p9; Mon, 22 Aug 2011 13:51:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta15.westchester.pa.mail.comcast.net with comcast id PRqr1h0150tdiYw3bRqwrJ; Mon, 22 Aug 2011 13:51:06 +0000 Message-ID: <4E525EB8.9050405@alum.mit.edu> Date: Mon, 22 Aug 2011 09:50:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Elwell, John" References: <4E3BFC29.6050001@alum.mit.edu><4E402C2F.1080103@alum.mit.edu><07465C1D981ABC41A344374066AE1A2C38B0304DA2@TLVMBX01.nice.com> <2E239D6FCD033C4BAF15F386A979BF510640D1@sonusinmail02.sonusnet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Do we need a stream element? 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, 22 Aug 2011 13:50:04 -0000 John, I went looking for a definition of media stream to borrow, and find that its not as easy to find as I thought it would be. For instance I didn't find it directly in RFC 4566 (SDP). SDP defines (multimedia) *session*. Within that it has "media description", which starts to get there. But it only deals with the mechanics, not the semantics, of the media stream. And its the semantics that we care about here. And RFC 3550 (RTP) suffers similarly. SDP defines session as: Session: A multimedia session is a set of multimedia senders and receivers and the data streams flowing from senders to receivers. A multimedia conference is an example of a multimedia session. From this we might extrapolate a definition for a Media Stream as: Media Stream: A media stream is a set of multimedia senders and receivers and a data stream flowing from senders to receivers. For siprec, we would narrow this: Media Stream: A media stream is a set of multimedia senders and receivers engaged in a communication session, and a data stream flowing from senders to receivers. This may still not be quite what it should be. I'm having difficulty capturing how multiple communication sessions fit into this. In the above my thought is that the senders and receivers must be in a CS, but they don't all have to be in the same one, or only one. Thanks, Paul On 8/22/11 3:08 AM, Elwell, John wrote: > Partha, > > Of course, we agreed an MS would have a unique identifier (June interim meeting), but what has emerged since then is that the unique identifier seems to be the only attribute needed for MS, which led me to doubt the need for the element in XML - just reference the SDP media description from participant send/recv elements. Having an explicit MS element with unique identifier seems to be a significant overhead for simple usages just to accommodate these more complex usages. I don't particularly want to re-open the old issue, but it concerns me that we don't have a clear definition of a MediaStream object. I can't find one in draft-03, It seems it represents neither a CS media stream (because some people insisted that a media stream can, under some circumstances, have a lifetime outside a single CS), nor an RS media stream (because of the arguments you make below). So what is it exactly? Please can somebody propose a clear and concise definition of a MediaStream object? > > John (as individual) > > >> -----Original Message----- >> From: Ravindran Parthasarathi [mailto:pravindran@sonusnet.com] >> Sent: 19 August 2011 18:42 >> To: Elwell, John; Charles Eckel (eckelcu); Leon Portman; Paul Kyzivat >> Cc: siprec@ietf.org >> Subject: RE: [siprec] Do we need a stream element? >> >> I remember that we have discussed during one of the interim before >> IETF-81 for the need of (Media) stream global-id which is >> different from >> label attribute in SDP. In case of RS to CS for 1:1 mapping, stream >> element and its global id looks overhead which I agree with John. >> >> I could recollect two of the scenario wherein stream element >> is useful: >> >> Scenario 1: CS:RS is in 1:N with multiple m-lines and unmixed >> stream to >> SRS. Here there is a need to map single stream with different RS SDP >> consistently using a unique id wherein stream global id shall be used. >> Few examples are >> A ) Typical call center scenario wherein single customer call is >> transferred to multiple agents in the single session. >> B) Start/Stop of CS which results in multiple RS. >> >> Scenario 2: Multicast scenario (Ram mentioned in another mail thread) >> >> In case better way to solve the above scenario, Please let us discuss >> about it. >> >> Thanks >> Partha >> >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Elwell, John >>> Sent: Thursday, August 18, 2011 4:05 PM >>> To: Charles Eckel (eckelcu); Leon Portman; Paul Kyzivat >>> Cc: siprec@ietf.org >>> Subject: Re: [siprec] Do we need a stream element? >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>>> Sent: 11 August 2011 16:44 >>>> To: Leon Portman; Paul Kyzivat; Elwell, John >>>> Cc: siprec@ietf.org >>>> Subject: RE: [siprec] Do we need a stream element? >>>> >>>> The media stream element was more intuitive to me when I >> understood >>> it >>>> to describe the CS media streams. Now that I understand it to >>>> be the RS >>>> media streams, I agree with John that the SDP could be sufficient. >>>> I believe I understand the points Paul and Leon are making >>>> with respect >>>> to long duration recordings; however, it does seem to me >> that we now >>>> have multiple mechanisms to describe very similar information (RS >>> SDP, >>>> RS media stream, send/recv elements). I would prefer to eliminate >>> some >>>> of the redundancy, otherwise I fear we will create >> duplications, and >>>> even worse, inconsistencies. >>> [JRE] Yes, that was basically my concern - redundant information >> and/or >>> too many ways to accomplish the same thing. >>> >>> John (as individual) >>> >>> >>>> >>>> Cheers, >>>> Charles >>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of Leon Portman >>>>> Sent: Wednesday, August 10, 2011 6:58 AM >>>>> To: Paul Kyzivat; Elwell, John >>>>> Cc: siprec@ietf.org >>>>> Subject: Re: [siprec] Do we need a stream element? >>>>> >>>>> I also think it will be cleaner to have dedicated MS element. We >>> can >>>> think about scenarios where it >>>>> can be "reused" by different participants. >>>>> >>>>> Leon >>>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of Paul Kyzivat >>>>> Sent: Monday, August 08, 2011 9:34 PM >>>>> To: Elwell, John >>>>> Cc: siprec@ietf.org >>>>> Subject: Re: [siprec] Do we need a stream element? >>>>> >>>>> On 8/8/11 4:08 AM, Elwell, John wrote: >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: siprec-bounces@ietf.org >>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>>>> Sent: 05 August 2011 15:20 >>>>>>> To: siprec@ietf.org >>>>>>> Subject: Re: [siprec] Do we need a stream element? >>>>>>> >>>>>>> John, >>>>>>> >>>>>>> On 8/5/11 5:03 AM, Elwell, John wrote: >>>>>>>> (as individual) >>>>>>>> >>>>>>>> Do we need a stream element in the XML? In Quebec we said >>>>>>> start and stop times should be tied to the >> association between >>>>>>> participant and stream, not to the stream itself. >>>>>>> This seems to suggest they be part of the send and recv >>>> sub-elements >>>>>>> of a participant element. The mode element also >> seems not to be >>>>>>> needed, since mixed or separate can be deduced from other >>>>>>> information. The only relevant information seems to be the >>> label. >>>>>>>> >>>>>>>> So it seems to be a waste of space for send and recv >>>>>>> sub-elements of a participant element to contain a unique ID >>>> pointing >>>>>>> to a stream element that then just contains a label. >>>>>>> Why don't the send and recv elements simply contain the >>>> label (plus >>>>>>> start and stop times, to meet what was decided in Quebec)? >>>>>>>> >>>>>>>> In other words, the MediaStream element in the model is >>>>>>> entirely represented by a media description in SDP. >>>>>>> >>>>>>> I think your point here is that the stream "class" will >>>> still exist >>>>>>> in the model, but its conveyed entirely in SDP and thus does >> not >>>> need >>>>>>> an xml representation. >>>>>>> >>>>>>> One thing the xml element provides is a way to assign a true >>>> globally >>>>>>> unique id, which allows the same stream to be referenced from >>>>>>> multiple recording sessions. Until now, we have not >> stated that >>>>>>> labels are unique ids. Rather, we have said (at least >>> informally) >>>>>>> that the labels are transient, used to bind the stream xml to >>> the >>>> SDP >>>>>>> within a single message. >>>>>> [JRE] From past discussions, I am led to believe that a stream >>>> element represents an RS stream, and >>>>> therefore the idea of having a unique ID that works from >>>> different RSs >>>> doesn't seem relevant. >>>>> >>>>> I suspect maybe we are still not all on the same page >> about this. >>>>> >>>>> Lets consider the case of a UA that is its own SRC. I pick that >>> case >>>>> simply because it is then plausible that it knows a fair >>>> amount about >>>>> the things it is recording. >>>>> >>>>> For instance, it might be an office phone, P, in an office >>>> that gets a >>>>> lot of calls and wants to record them all. It could >>>> establish an RS at >>>>> the beginning of the day, and use it for all calls in >> which it is >>>> involved. >>>>> >>>>> Assume P makes a voice call to A. Then after that >>>> completes, P gets a >>>>> call from B, and that completes. >>>>> >>>>> If P does its own mixing, then it needs only a single >>>> m-line in the RS >>>>> to accomplish this, using if first for the call with A and then >> for >>>> the >>>>> call with B. >>>>> >>>>> The question is whether that is one MS object, or two. >>>>> >>>>> There will be two session elements, one for each call. Each >>>> will refer >>>>> to one MS element - either the same one, or a different >>>> one. If its a >>>>> single one, then for the duration of the first call the >>> participants >>>> of >>>>> the MS will be P and A, while during the 2nd call the >> participants >>>> will >>>>> be P& B. Is that enough for the SRS to understand what is going >>> on? >>>>> >>>>> It gets more complex of the two calls are overlapped in >>>> time. Perhaps >>>>> the call from B comes before the call with A is over. >> So P puts A >>> on >>>>> hold, answers and completes the call with B and then >>>> resumes the call >>>>> with A. >>>>> >>>>> In that case, if there is no MoH, P may still need only a single >>>> m-line >>>>> in the RS to handle this. Then, the participants for the only MS >>> are >>>>> first P&A, then P&B, then P&A. The MS would then need to be >>> switched >>>>> from the first session, to the second, and back to the first. >>>>> >>>>> I think this *can* work either way, and is to some extent a >>>> matter of >>>>> taste. But it has to be carefully documented one way or the >>>> other. In >>>>> *my* mind having separate MS objects makes sense, but maybe that >> is >>>> just >>>>> a bias on my part. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> >>>>>>> I suppose we *could* specify a UUID representation that can >>>>>>> be used as a >>>>>>> label in SDP. (That is possible, but would have to be an >>>>>>> unusual radix64 >>>>>>> representation, or we could use hex.) >>>>>>> >>>>>>> I'm a bit reluctant to go this way because it eliminates the >>>>>>> opportunity >>>>>>> to associate other data with a stream, including extension >> data. >>>> But >>>>>>> lets discuss it further. >>>>>> [JRE] I see your point, but would such extension data be more >>>> appropriate as part of a send or recv >>>>> element? >>>>> >>>>> I think either place could make sense, but for different things. >>>>> If you have data about why the sending is taking place >> or what it >>> is >>>>> about, then that belongs on the element. If you have data >> on >>>> why >>>>> the stream as a whole exists, regardless of sender, then >>>> extending the >>>>> MS makes more sense. (But if the MS merely represents the m-line >> in >>>> the >>>>> RS, then metadata on it probably doesn't make much sense.) >>>>> >>>>> Thanks >>>>> Paul >>>>> >>>>> >>>>>> John Elwell >>>>>> Tel: +44 1908 817801 (office and mobile) >>>>>> Email: john.elwell@siemens-enterprise.com >>>>>> http://www.siemens-enterprise.com/uk/ >>>>>> >>>>>> Siemens Enterprise Communications Limited. >>>>>> Registered office: Brickhill Street, Willen Lake, >> Milton Keynes, >>>> MK15 0DJ. >>>>>> Registered No: 5903714, England. >>>>>> >>>>>> Siemens Enterprise Communications Limited is a Trademark >>>> Licensee of >>>> Siemens AG. >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>>> For example, the schema might look something like this: >>>>>>>> >>>>>>>> >>>>>>> minOccurs="0" maxOccurs="unbounded"/> >>>>>>>> >>>>>>> minOccurs="0" maxOccurs="unbounded"/> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> minOccurs="0" maxOccurs="1"/> >>>>>>>> >>>>>>> minOccurs="0"/> >>>>>>>> >>>>>>> minOccurs="0"/> >>>>>>>> >>>>>>> minOccurs="0"/> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> John >>>>>>>> _______________________________________________ >>>>>>>> siprec mailing list >>>>>>>> siprec@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> siprec mailing list >>>>>>> siprec@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>> >>>>> >>>>> _______________________________________________ >>>>> siprec mailing 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 Aug 22 06:55:20 2011 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 879EF21F8511 for ; Mon, 22 Aug 2011 06:55:20 -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.150, BAYES_00=-2.599, J_CHICKENPOX_22=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 gvA5m1IIsMQ8 for ; Mon, 22 Aug 2011 06:55:19 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB1C21F84F7 for ; Mon, 22 Aug 2011 06:55:19 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p7MDumGH030092; Mon, 22 Aug 2011 09:56:48 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Aug 2011 09:56:20 -0400 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, 22 Aug 2011 19:26:16 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF5106416E@sonusinmail02.sonusnet.com> In-Reply-To: <4E525EB8.9050405@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Do we need a stream element? Thread-Index: Acxg0o2Ob/88cgnZRlOOUCFmhiIhXAAAHKQQ References: <4E3BFC29.6050001@alum.mit.edu><4E402C2F.1080103@alum.mit.edu><07465C1D981ABC41A344374066AE1A2C38B0304DA2@TLVMBX01.nice.com> <2E239D6FCD033C4BAF15F386A979BF510640D1@sonusinmail02.sonusnet.com> <4E525EB8.9050405@alum.mit.edu> From: "Ravindran Parthasarathi" To: "Paul Kyzivat" , "Elwell, John" X-OriginalArrivalTime: 22 Aug 2011 13:56:20.0603 (UTC) FILETIME=[456CDCB0:01CC60D3] Cc: siprec@ietf.org Subject: Re: [siprec] Do we need a stream element? 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, 22 Aug 2011 13:55:20 -0000 Paul, Please read inline. Thanks Partha >-----Original Message----- >From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >Sent: Monday, August 22, 2011 7:21 PM >To: Elwell, John >Cc: Ravindran Parthasarathi; Charles Eckel (eckelcu); Leon Portman; >siprec@ietf.org >Subject: Re: [siprec] Do we need a stream element? > >John, > >I went looking for a definition of media stream to borrow, and find that >its not as easy to find as I thought it would be. For instance I didn't >find it directly in RFC 4566 (SDP). > >SDP defines (multimedia) *session*. Within that it has "media >description", which starts to get there. But it only deals with the >mechanics, not the semantics, of the media stream. And its the semantics >that we care about here. And RFC 3550 (RTP) suffers similarly. > >SDP defines session as: > > Session: A multimedia session is a set of multimedia senders and > receivers and the data streams flowing from senders to receivers. > A multimedia conference is an example of a multimedia session. > > From this we might extrapolate a definition for a Media Stream as: > > Media Stream: A media stream is a set of multimedia senders and > receivers and a data stream flowing from senders to receivers. > >For siprec, we would narrow this: > > Media Stream: A media stream is a set of multimedia senders and > receivers engaged in a communication session, and a data stream > flowing from senders to receivers. > [Partha] How about including communication session group instead of communication session. So, the updated definition is=20 Media Stream: A media stream is a set of multimedia senders and receivers engaged in a communication session group, and a data stream flowing from senders to receivers. >This may still not be quite what it should be. I'm having difficulty >capturing how multiple communication sessions fit into this. In the >above my thought is that the senders and receivers must be in a CS, but >they don't all have to be in the same one, or only one. > > Thanks, > Paul > > > >On 8/22/11 3:08 AM, Elwell, John wrote: >> Partha, >> >> Of course, we agreed an MS would have a unique identifier (June >interim meeting), but what has emerged since then is that the unique >identifier seems to be the only attribute needed for MS, which led me to >doubt the need for the element in XML - just reference the SDP media >description from participant send/recv elements. Having an explicit MS >element with unique identifier seems to be a significant overhead for >simple usages just to accommodate these more complex usages. I don't >particularly want to re-open the old issue, but it concerns me that we >don't have a clear definition of a MediaStream object. I can't find one >in draft-03, It seems it represents neither a CS media stream (because >some people insisted that a media stream can, under some circumstances, >have a lifetime outside a single CS), nor an RS media stream (because of >the arguments you make below). So what is it exactly? Please can >somebody propose a clear and concise definition of a MediaStream object? >> >> John (as individual) >> >> >>> -----Original Message----- >>> From: Ravindran Parthasarathi [mailto:pravindran@sonusnet.com] >>> Sent: 19 August 2011 18:42 >>> To: Elwell, John; Charles Eckel (eckelcu); Leon Portman; Paul Kyzivat >>> Cc: siprec@ietf.org >>> Subject: RE: [siprec] Do we need a stream element? >>> >>> I remember that we have discussed during one of the interim before >>> IETF-81 for the need of (Media) stream global-id which is >>> different from >>> label attribute in SDP. In case of RS to CS for 1:1 mapping, stream >>> element and its global id looks overhead which I agree with John. >>> >>> I could recollect two of the scenario wherein stream element >>> is useful: >>> >>> Scenario 1: CS:RS is in 1:N with multiple m-lines and unmixed >>> stream to >>> SRS. Here there is a need to map single stream with different RS SDP >>> consistently using a unique id wherein stream global id shall be >used. >>> Few examples are >>> A ) Typical call center scenario wherein single customer call is >>> transferred to multiple agents in the single session. >>> B) Start/Stop of CS which results in multiple RS. >>> >>> Scenario 2: Multicast scenario (Ram mentioned in another mail thread) >>> >>> In case better way to solve the above scenario, Please let us discuss >>> about it. >>> >>> Thanks >>> Partha >>> >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of Elwell, John >>>> Sent: Thursday, August 18, 2011 4:05 PM >>>> To: Charles Eckel (eckelcu); Leon Portman; Paul Kyzivat >>>> Cc: siprec@ietf.org >>>> Subject: Re: [siprec] Do we need a stream element? >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>>>> Sent: 11 August 2011 16:44 >>>>> To: Leon Portman; Paul Kyzivat; Elwell, John >>>>> Cc: siprec@ietf.org >>>>> Subject: RE: [siprec] Do we need a stream element? >>>>> >>>>> The media stream element was more intuitive to me when I >>> understood >>>> it >>>>> to describe the CS media streams. Now that I understand it to >>>>> be the RS >>>>> media streams, I agree with John that the SDP could be sufficient. >>>>> I believe I understand the points Paul and Leon are making >>>>> with respect >>>>> to long duration recordings; however, it does seem to me >>> that we now >>>>> have multiple mechanisms to describe very similar information (RS >>>> SDP, >>>>> RS media stream, send/recv elements). I would prefer to eliminate >>>> some >>>>> of the redundancy, otherwise I fear we will create >>> duplications, and >>>>> even worse, inconsistencies. >>>> [JRE] Yes, that was basically my concern - redundant information >>> and/or >>>> too many ways to accomplish the same thing. >>>> >>>> John (as individual) >>>> >>>> >>>>> >>>>> Cheers, >>>>> Charles >>>>> >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org] On >>>>> Behalf Of Leon Portman >>>>>> Sent: Wednesday, August 10, 2011 6:58 AM >>>>>> To: Paul Kyzivat; Elwell, John >>>>>> Cc: siprec@ietf.org >>>>>> Subject: Re: [siprec] Do we need a stream element? >>>>>> >>>>>> I also think it will be cleaner to have dedicated MS element. We >>>> can >>>>> think about scenarios where it >>>>>> can be "reused" by different participants. >>>>>> >>>>>> Leon >>>>>> >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org] On >>>>> Behalf Of Paul Kyzivat >>>>>> Sent: Monday, August 08, 2011 9:34 PM >>>>>> To: Elwell, John >>>>>> Cc: siprec@ietf.org >>>>>> Subject: Re: [siprec] Do we need a stream element? >>>>>> >>>>>> On 8/8/11 4:08 AM, Elwell, John wrote: >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: siprec-bounces@ietf.org >>>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>>>>> Sent: 05 August 2011 15:20 >>>>>>>> To: siprec@ietf.org >>>>>>>> Subject: Re: [siprec] Do we need a stream element? >>>>>>>> >>>>>>>> John, >>>>>>>> >>>>>>>> On 8/5/11 5:03 AM, Elwell, John wrote: >>>>>>>>> (as individual) >>>>>>>>> >>>>>>>>> Do we need a stream element in the XML? In Quebec we said >>>>>>>> start and stop times should be tied to the >>> association between >>>>>>>> participant and stream, not to the stream itself. >>>>>>>> This seems to suggest they be part of the send and recv >>>>> sub-elements >>>>>>>> of a participant element. The mode element also >>> seems not to be >>>>>>>> needed, since mixed or separate can be deduced from other >>>>>>>> information. The only relevant information seems to be the >>>> label. >>>>>>>>> >>>>>>>>> So it seems to be a waste of space for send and recv >>>>>>>> sub-elements of a participant element to contain a unique ID >>>>> pointing >>>>>>>> to a stream element that then just contains a label. >>>>>>>> Why don't the send and recv elements simply contain the >>>>> label (plus >>>>>>>> start and stop times, to meet what was decided in Quebec)? >>>>>>>>> >>>>>>>>> In other words, the MediaStream element in the model is >>>>>>>> entirely represented by a media description in SDP. >>>>>>>> >>>>>>>> I think your point here is that the stream "class" will >>>>> still exist >>>>>>>> in the model, but its conveyed entirely in SDP and thus does >>> not >>>>> need >>>>>>>> an xml representation. >>>>>>>> >>>>>>>> One thing the xml element provides is a way to assign a true >>>>> globally >>>>>>>> unique id, which allows the same stream to be referenced from >>>>>>>> multiple recording sessions. Until now, we have not >>> stated that >>>>>>>> labels are unique ids. Rather, we have said (at least >>>> informally) >>>>>>>> that the labels are transient, used to bind the stream xml to >>>> the >>>>> SDP >>>>>>>> within a single message. >>>>>>> [JRE] From past discussions, I am led to believe that a stream >>>>> element represents an RS stream, and >>>>>> therefore the idea of having a unique ID that works from >>>>> different RSs >>>>> doesn't seem relevant. >>>>>> >>>>>> I suspect maybe we are still not all on the same page >>> about this. >>>>>> >>>>>> Lets consider the case of a UA that is its own SRC. I pick that >>>> case >>>>>> simply because it is then plausible that it knows a fair >>>>> amount about >>>>>> the things it is recording. >>>>>> >>>>>> For instance, it might be an office phone, P, in an office >>>>> that gets a >>>>>> lot of calls and wants to record them all. It could >>>>> establish an RS at >>>>>> the beginning of the day, and use it for all calls in >>> which it is >>>>> involved. >>>>>> >>>>>> Assume P makes a voice call to A. Then after that >>>>> completes, P gets a >>>>>> call from B, and that completes. >>>>>> >>>>>> If P does its own mixing, then it needs only a single >>>>> m-line in the RS >>>>>> to accomplish this, using if first for the call with A and then >>> for >>>>> the >>>>>> call with B. >>>>>> >>>>>> The question is whether that is one MS object, or two. >>>>>> >>>>>> There will be two session elements, one for each call. Each >>>>> will refer >>>>>> to one MS element - either the same one, or a different >>>>> one. If its a >>>>>> single one, then for the duration of the first call the >>>> participants >>>>> of >>>>>> the MS will be P and A, while during the 2nd call the >>> participants >>>>> will >>>>>> be P& B. Is that enough for the SRS to understand what is going >>>> on? >>>>>> >>>>>> It gets more complex of the two calls are overlapped in >>>>> time. Perhaps >>>>>> the call from B comes before the call with A is over. >>> So P puts A >>>> on >>>>>> hold, answers and completes the call with B and then >>>>> resumes the call >>>>>> with A. >>>>>> >>>>>> In that case, if there is no MoH, P may still need only a single >>>>> m-line >>>>>> in the RS to handle this. Then, the participants for the only MS >>>> are >>>>>> first P&A, then P&B, then P&A. The MS would then need to be >>>> switched >>>>>> from the first session, to the second, and back to the first. >>>>>> >>>>>> I think this *can* work either way, and is to some extent a >>>>> matter of >>>>>> taste. But it has to be carefully documented one way or the >>>>> other. In >>>>>> *my* mind having separate MS objects makes sense, but maybe that >>> is >>>>> just >>>>>> a bias on my part. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> >>>>>>>> I suppose we *could* specify a UUID representation that can >>>>>>>> be used as a >>>>>>>> label in SDP. (That is possible, but would have to be an >>>>>>>> unusual radix64 >>>>>>>> representation, or we could use hex.) >>>>>>>> >>>>>>>> I'm a bit reluctant to go this way because it eliminates the >>>>>>>> opportunity >>>>>>>> to associate other data with a stream, including extension >>> data. >>>>> But >>>>>>>> lets discuss it further. >>>>>>> [JRE] I see your point, but would such extension data be more >>>>> appropriate as part of a send or recv >>>>>> element? >>>>>> >>>>>> I think either place could make sense, but for different things. >>>>>> If you have data about why the sending is taking place >>> or what it >>>> is >>>>>> about, then that belongs on the element. If you have data >>> on >>>>> why >>>>>> the stream as a whole exists, regardless of sender, then >>>>> extending the >>>>>> MS makes more sense. (But if the MS merely represents the m-line >>> in >>>>> the >>>>>> RS, then metadata on it probably doesn't make much sense.) >>>>>> >>>>>> Thanks >>>>>> Paul >>>>>> >>>>>> >>>>>>> John Elwell >>>>>>> Tel: +44 1908 817801 (office and mobile) >>>>>>> Email: john.elwell@siemens-enterprise.com >>>>>>> http://www.siemens-enterprise.com/uk/ >>>>>>> >>>>>>> Siemens Enterprise Communications Limited. >>>>>>> Registered office: Brickhill Street, Willen Lake, >>> Milton Keynes, >>>>> MK15 0DJ. >>>>>>> Registered No: 5903714, England. >>>>>>> >>>>>>> Siemens Enterprise Communications Limited is a Trademark >>>>> Licensee of >>>>> Siemens AG. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>>>> For example, the schema might look something like this: >>>>>>>>> >>>>>>>>> >>>>>>>> minOccurs=3D"0" maxOccurs=3D"unbounded"/> >>>>>>>>> >>>>>>>> minOccurs=3D"0" maxOccurs=3D"unbounded"/> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> minOccurs=3D"0" maxOccurs=3D"1"/> >>>>>>>>> >>>>>>>> minOccurs=3D"0"/> >>>>>>>>> >>>>>>>> minOccurs=3D"0"/> >>>>>>>>> >>>>>>>> minOccurs=3D"0"/> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> John >>>>>>>>> _______________________________________________ >>>>>>>>> siprec mailing list >>>>>>>>> siprec@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> siprec mailing list >>>>>>>> siprec@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> siprec mailing list >>>>>> siprec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>> _______________________________________________ >>>>>> siprec mailing list >>>>>> siprec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>> From pkyzivat@alum.mit.edu Mon Aug 22 07:32:27 2011 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 E2FE821F8686 for ; Mon, 22 Aug 2011 07:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 RDwDt8iJqmi6 for ; Mon, 22 Aug 2011 07:32:27 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id EE5E121F85FE for ; Mon, 22 Aug 2011 07:32:26 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta02.westchester.pa.mail.comcast.net with comcast id PSV51h00416LCl052SZYVX; Mon, 22 Aug 2011 14:33:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta06.westchester.pa.mail.comcast.net with comcast id PSYv1h02A0tdiYw3SSZ4V7; Mon, 22 Aug 2011 14:33:30 +0000 Message-ID: <4E526896.60505@alum.mit.edu> Date: Mon, 22 Aug 2011 10:32:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Ravindran Parthasarathi References: <4E3BFC29.6050001@alum.mit.edu><4E402C2F.1080103@alum.mit.edu><07465C1D981ABC41A344374066AE1A2C38B0304DA2@TLVMBX01.nice.com> <2E239D6FCD033C4BAF15F386A979BF510640D1@sonusinmail02.sonusnet.com> <4E525EB8.9050405@alum.mit.edu> <2E239D6FCD033C4BAF15F386A979BF5106416E@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF5106416E@sonusinmail02.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] Do we need a stream element? 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, 22 Aug 2011 14:32:28 -0000 On 8/22/11 9:56 AM, Ravindran Parthasarathi wrote: > Paul, > > Please read inline. > > Thanks > Partha > >> -----Original Message----- >> From this we might extrapolate a definition for a Media Stream as: >> >> Media Stream: A media stream is a set of multimedia senders and >> receivers and a data stream flowing from senders to receivers. >> >> For siprec, we would narrow this: >> >> Media Stream: A media stream is a set of multimedia senders and >> receivers engaged in a communication session, and a data stream >> flowing from senders to receivers. >> > [Partha] How about including communication session group instead of > communication session. So, the updated definition is > > Media Stream: A media stream is a set of multimedia senders and > receivers engaged in a communication session group, and a data > stream > flowing from senders to receivers. I don't think this is right, for a variety of reasons: - it seems to suggest that you can't be a sender or receiver to an MS unless you are in a CSG. That isn't consistent with how we have things. - I presume by this change that you are suggesting that those cases where a MS is in more than one CS are also cases where those CSs are in a group. But I don't think that is always the case. I'm thinking of a multicast MS used for MoH, that may be shared by all CSs that are using it for their MoH media. But I think this does expose some added trouble with my definition as well. Specifically, we separate the MS from the senders/receivers of that media stream, considering it to be the same stream even as the senders and receivers change over time. (I was going to refer to George Washington's axe here, but see http://en.wikipedia.org/wiki/Ship_of_Theseus for a more culturally neutral treatment of the same point.) So, to take another crack at it: Media Stream: A data stream flowing between an evolving set of senders and receivers engaged with one another in one or more communication sessions. Thanks, Paul From john.elwell@siemens-enterprise.com Mon Aug 22 08:02:25 2011 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 4EF2B21F8B75 for ; Mon, 22 Aug 2011 08:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.251 X-Spam-Level: X-Spam-Status: No, score=-103.251 tagged_above=-999 required=5 tests=[AWL=-0.652, 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 EITg5bAQU5ko for ; Mon, 22 Aug 2011 08:02:24 -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 3B1CF21F8584 for ; Mon, 22 Aug 2011 08:02:24 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 1B26B1EB8452; Mon, 22 Aug 2011 17:03:29 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 22 Aug 2011 17:03:29 +0200 From: "Elwell, John" To: Paul Kyzivat , Ravindran Parthasarathi Date: Mon, 22 Aug 2011 17:03:28 +0200 Thread-Topic: [siprec] Do we need a stream element? Thread-Index: Acxg2HfcNeaKPO3vRNGuvt5VIrQhaQAAunaw Message-ID: References: <4E3BFC29.6050001@alum.mit.edu><4E402C2F.1080103@alum.mit.edu><07465C1D981ABC41A344374066AE1A2C38B0304DA2@TLVMBX01.nice.com> <2E239D6FCD033C4BAF15F386A979BF510640D1@sonusinmail02.sonusnet.com> <4E525EB8.9050405@alum.mit.edu> <2E239D6FCD033C4BAF15F386A979BF5106416E@sonusinmail02.sonusnet.com> <4E526896.60505@alum.mit.edu> In-Reply-To: <4E526896.60505@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Do we need a stream element? 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, 22 Aug 2011 15:02:25 -0000 Paul,=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 > Sent: 22 August 2011 15:33 > To: Ravindran Parthasarathi > Cc: Elwell, John; Charles Eckel (eckelcu); Leon Portman;=20 > siprec@ietf.org > Subject: Re: [siprec] Do we need a stream element? >=20 > On 8/22/11 9:56 AM, Ravindran Parthasarathi wrote: > > Paul, > > > > Please read inline. > > > > Thanks > > Partha > > > >> -----Original Message----- >=20 > >> From this we might extrapolate a definition for a Media Stream as: > >> > >> Media Stream: A media stream is a set of multimedia senders and > >> receivers and a data stream flowing from senders to=20 > receivers. > >> > >> For siprec, we would narrow this: > >> > >> Media Stream: A media stream is a set of multimedia senders and > >> receivers engaged in a communication session, and a=20 > data stream > >> flowing from senders to receivers. > >> > > [Partha] How about including communication session group instead of > > communication session. So, the updated definition is > > > > Media Stream: A media stream is a set of multimedia senders and > > receivers engaged in a communication session group,=20 > and a data > > stream > > flowing from senders to receivers. >=20 > I don't think this is right, for a variety of reasons: >=20 > - it seems to suggest that you can't be a sender or receiver to an MS > unless you are in a CSG. That isn't consistent with how we have > things. >=20 > - I presume by this change that you are suggesting that those cases > where a MS is in more than one CS are also cases where=20 > those CSs are > in a group. But I don't think that is always the case. I'm thinking > of a multicast MS used for MoH, that may be shared by all CSs that > are using it for their MoH media. >=20 > But I think this does expose some added trouble with my definition as=20 > well. Specifically, we separate the MS from the senders/receivers of=20 > that media stream, considering it to be the same stream even as the=20 > senders and receivers change over time. >=20 > (I was going to refer to George Washington's axe here, but see=20 > http://en.wikipedia.org/wiki/Ship_of_Theseus for a more culturally=20 > neutral treatment of the same point.) >=20 > So, to take another crack at it: >=20 > Media Stream: A data stream flowing between an evolving set of > senders and receivers engaged with one another in one or more > communication sessions. [JRE] Thanks for attempting to find a definition. I think this about captur= es where we are, but in my opinion it is still rather vague - from this def= inition it isn't coupled to an RS, and although coupled to one or more CSs,= is not constrained to a single CS. So, as an SRC, what criteria would I us= e to decide whether data streams from two CSs are really a single Media Str= eam object or two Media Stream objects? In the object-orientated world, one usually tries to define an object class= to represent a tangible set of objects in some way - if you can't define w= hat these objects are, this might be good grounds for questioning your choi= ce of object class. For me, it is the same here. I am uncomfortable with th= is class, simply because we are having difficulty deciding when something i= s a single object of this class and when it is several. John (as individual) John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. >=20 > Thanks, > Paul > = From pkyzivat@alum.mit.edu Mon Aug 22 08:30:37 2011 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 6A8BA21F8B2D for ; Mon, 22 Aug 2011 08:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 bqPSAAfDVJuH for ; Mon, 22 Aug 2011 08:30:36 -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 9DE4921F8B21 for ; Mon, 22 Aug 2011 08:30:36 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta15.westchester.pa.mail.comcast.net with comcast id PTWH1h0011vXlb85FTXiK3; Mon, 22 Aug 2011 15:31:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta17.westchester.pa.mail.comcast.net with comcast id PTXL1h0310tdiYw3dTXVJP; Mon, 22 Aug 2011 15:31:40 +0000 Message-ID: <4E527645.5060807@alum.mit.edu> Date: Mon, 22 Aug 2011 11:31:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Elwell, John" References: <4E3BFC29.6050001@alum.mit.edu><4E402C2F.1080103@alum.mit.edu><07465C1D981ABC41A344374066AE1A2C38B0304DA2@TLVMBX01.nice.com> <2E239D6FCD033C4BAF15F386A979BF510640D1@sonusinmail02.sonusnet.com> <4E525EB8.9050405@alum.mit.edu> <2E239D6FCD033C4BAF15F386A979BF5106416E@sonusinmail02.sonusnet.com> <4E526896.60505@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Do we need a stream element? 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, 22 Aug 2011 15:30:37 -0000 On 8/22/11 11:03 AM, Elwell, John wrote: > Paul, >> So, to take another crack at it: >> >> Media Stream: A data stream flowing between an evolving set of >> senders and receivers engaged with one another in one or more >> communication sessions. > [JRE] Thanks for attempting to find a definition. I think this about captures where we are, but in my opinion it is still rather vague - from this definition it isn't coupled to an RS, and although coupled to one or more CSs, is not constrained to a single CS. So, as an SRC, what criteria would I use to decide whether data streams from two CSs are really a single Media Stream object or two Media Stream objects? > > In the object-orientated world, one usually tries to define an object class to represent a tangible set of objects in some way - if you can't define what these objects are, this might be good grounds for questioning your choice of object class. For me, it is the same here. I am uncomfortable with this class, simply because we are having difficulty deciding when something is a single object of this class and when it is several. > > John (as individual) John, I share your discomfort - I don't think the definition is right yet. But I do think there is a concept there needing a definition. Some *examples* of this: - my "side" of the audio part of a conversation with you, contained within a CS between you and me. - my "side" of the audio part of a conversation with a call center agent, contained within a CS between me and him, but also going to the call center supervisor who is listening in. - a mix of the audio part of a conversation between me and you, from my perspective, including the audio I sent to you and the audio I received from you. - a MoH audio stream generated and sent by your phone when you put me on hold. - a MoH audio stream sent by an MoH server to whom I have been transferred while on hold. A unique stream generated for me. - a MoH multicast audio stream that was offered to me by you when you put me on hold. That same stream has been shared by all those put on hold by the PBX you use. - a mixed audio stream for a conference. It contains a mix of the loudest two participants at any one time. In each case, the media stream exists over a period of time. The contents of the stream can be forwarded to the SRS using one of the RTP streams in an RS. And portions of that MS might be forwarded using different RTP streams and/or RSs. Without yet nailing down the definition, do you agree that there is a well defined concept (class) here? Thanks, Paul From trac+siprec@trac.tools.ietf.org Mon Aug 22 11:16:23 2011 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 CFC5F21F8B19 for ; Mon, 22 Aug 2011 11:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 KXAAD5-OSjsm for ; Mon, 22 Aug 2011 11:16:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:123a::1:2a]) by ietfa.amsl.com (Postfix) with ESMTP id 7729B21F8B01 for ; Mon, 22 Aug 2011 11:16:22 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QvZ3w-00082Z-JX; Mon, 22 Aug 2011 11:17:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "siprec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: rmohanr@cisco.com, partr@cisco.com X-Trac-Project: siprec Date: Mon, 22 Aug 2011 18:17:28 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/68#comment:1 Message-ID: <084.53cdc48fc0a5a2dadeb3fd8d93617fb2@trac.tools.ietf.org> References: <075.db8ff04b7cbf099d401d476dc3008b5f@trac.tools.ietf.org> X-Trac-Ticket-ID: 68 In-Reply-To: <075.db8ff04b7cbf099d401d476dc3008b5f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rmohanr@cisco.com, partr@cisco.com, siprec@ietf.org X-SA-Exim-Mail-From: trac+siprec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: siprec@ietf.org Subject: Re: [siprec] #68: Start/stop time for Recording Session X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 18:16:23 -0000 #68: Start/stop time for Recording Session Changes (by partr@…): * status: new => closed * resolution: => fixed -- ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: rmohanr@… Type: defect | Status: closed Priority: minor | Milestone: Component: Metadata Model | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ------------------------------------------------+--------------------------- Ticket URL: siprec From pravindran@sonusnet.com Mon Aug 22 11:45:52 2011 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 C258221F8A91 for ; Mon, 22 Aug 2011 11:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 sCAQ7DjuB8yo for ; Mon, 22 Aug 2011 11:45:52 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6DD21F87D9 for ; Mon, 22 Aug 2011 11:45:51 -0700 (PDT) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p7MIlNvI026263; Mon, 22 Aug 2011 14:47:23 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Aug 2011 14:46:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Aug 2011 00:16:51 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51064182@sonusinmail02.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SRC decomposition figures in SIPREC architecture doc[FW: [rtcweb] Use cases - recording and voicemail] Thread-Index: AcxfUMTfEVJBuTF0R9mTlWEWeaGpTgBW0F+AABPBSwA= From: "Ravindran Parthasarathi" To: X-OriginalArrivalTime: 22 Aug 2011 18:46:55.0953 (UTC) FILETIME=[DDB42410:01CC60FB] Subject: [siprec] SRC decomposition figures in SIPREC architecture doc[FW: [rtcweb] Use cases - recording and voicemail] 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, 22 Aug 2011 18:45:52 -0000 FYI... RTCWeb is an one another example where SRC/SRS decomposition architecture has to be explained in detail. As Andy mentioned below, it is better to add more SRC/SRS decomposition figure for future reference. Thanks Partha -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Hutton, Andrew Sent: Monday, August 22, 2011 2:56 PM To: Harald Alvestrand Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Use cases - recording and voicemail >=20 > RTCWEB doesn't seem to going in the direction of mandating SIP, but > still, I would think that it is reasonable to say something along the > lines of "the remote recording case is handled by connecting to a > SIPREC-capable recorder" (with the usual degree of gatewaying help from > our signaling proxies). >=20 [AndyH] - I agree this would just seem to be another example of how the Session Recording Client can be decomposed and is similar to Figure 4 in the SIPREC architecture draft (http://tools.ietf.org/html/draft-ietf-siprec-architecture-02#section-3. 1.2) but in the case of RTCWEB the media server is the browser and the application is the web server and of course RTCWEB will not use mediactrl. I have been resisting attempts to add more diagrams to the SIPREC architecture draft to show the multitude of ways the SRC and SRS could be decomposed but maybe RTCWEB is a good reason to do this. > That will, of course, require that the SIPREC recorder is capable of > participiating in an RTCWEB session (that is, support ICE and the > mandatory codecs), that the RTCWEB implementation be capable of copying > incoming media streams to an outgoing interface, and that negotiation > can down-negotiate to something that is supported by both call > participants and the recording device. Does SIPREC envision > establishing > minimum requirements for codec's and profiles? [AndyH] - No the SIPREC requirements (http://tools.ietf.org/html/rfc6341) don't include minimum codec requirements. >=20 > Once we can satisfy ourselves that we have all the pieces required to > send media off to a remote API, we should see if we can do something > very similar for sending media off to some kind of local recorder; it > seems less likely that we'll get into trouble with locking ourselves > into a wrong model if we do things in that order. >=20 > My $0.02. >=20 > Harald >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From Leon.Portman@nice.com Mon Aug 22 23:09:30 2011 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 8FB7821F8AF6 for ; Mon, 22 Aug 2011 23:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 NgxKcCcSSEo5 for ; Mon, 22 Aug 2011 23:09:29 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id D4AE021F8AF2 for ; Mon, 22 Aug 2011 23:09:28 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Tue, 23 Aug 2011 09:10:35 +0300 From: Leon Portman To: Ravindran Parthasarathi , "siprec@ietf.org" Date: Tue, 23 Aug 2011 09:10:22 +0300 Thread-Topic: SRC decomposition figures in SIPREC architecture doc[FW: [rtcweb] Use cases - recording and voicemail] Thread-Index: AcxfUMTfEVJBuTF0R9mTlWEWeaGpTgBW0F+AABPBSwAAGAgwIA== Message-ID: <07465C1D981ABC41A344374066AE1A2C38B03CAD3F@TLVMBX01.nice.com> References: <2E239D6FCD033C4BAF15F386A979BF51064182@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51064182@sonusinmail02.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 Subject: Re: [siprec] SRC decomposition figures in SIPREC architecture doc[FW: [rtcweb] Use cases - recording and voicemail] 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, 23 Aug 2011 06:09:30 -0000 Partha Hi I will prepare and propose some drawing to demonstrate such decomposition. Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Ravindran Parthasarathi Sent: Monday, August 22, 2011 9:47 PM To: siprec@ietf.org Subject: [siprec] SRC decomposition figures in SIPREC architecture doc[FW: = [rtcweb] Use cases - recording and voicemail] FYI... RTCWeb is an one another example where SRC/SRS decomposition architecture h= as to be explained in detail. As Andy mentioned below, it is better to add = more SRC/SRS decomposition figure for future reference. Thanks Partha -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Hutton, Andrew Sent: Monday, August 22, 2011 2:56 PM To: Harald Alvestrand Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Use cases - recording and voicemail >=20 > RTCWEB doesn't seem to going in the direction of mandating SIP, but=20 > still, I would think that it is reasonable to say something along the=20 > lines of "the remote recording case is handled by connecting to a=20 > SIPREC-capable recorder" (with the usual degree of gatewaying help from > our signaling proxies). >=20 [AndyH] - I agree this would just seem to be another example of how the Ses= sion Recording Client can be decomposed and is similar to Figure 4 in the S= IPREC architecture draft (http://tools.ietf.org/html/draft-ietf-siprec-arch= itecture-02#section-3. 1.2) but in the case of RTCWEB the media server is the browser and the appl= ication is the web server and of course RTCWEB will not use mediactrl. I ha= ve been resisting attempts to add more diagrams to the SIPREC architecture = draft to show the multitude of ways the SRC and SRS could be decomposed but= maybe RTCWEB is a good reason to do this. > That will, of course, require that the SIPREC recorder is capable of=20 > participiating in an RTCWEB session (that is, support ICE and the=20 > mandatory codecs), that the RTCWEB implementation be capable of copying > incoming media streams to an outgoing interface, and that negotiation=20 > can down-negotiate to something that is supported by both call=20 > participants and the recording device. Does SIPREC envision=20 > establishing minimum requirements for codec's and profiles? [AndyH] - No the SIPREC requirements (http://tools.ietf.org/html/rfc6341) don't include minimum codec requiremen= ts. >=20 > Once we can satisfy ourselves that we have all the pieces required to=20 > send media off to a remote API, we should see if we can do something=20 > very similar for sending media off to some kind of local recorder; it=20 > seems less likely that we'll get into trouble with locking ourselves=20 > into a wrong model if we do things in that order. >=20 > My $0.02. >=20 > Harald >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Tue Aug 23 01:01:17 2011 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 BA8B721F85BB for ; Tue, 23 Aug 2011 01:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.216 X-Spam-Level: X-Spam-Status: No, score=-103.216 tagged_above=-999 required=5 tests=[AWL=-0.617, 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 pGJdksWGsmVy for ; Tue, 23 Aug 2011 01:01: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 930CE21F85B8 for ; Tue, 23 Aug 2011 01:01:16 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 5016E23F04A5 for ; Tue, 23 Aug 2011 10:02:23 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 23 Aug 2011 10:02:23 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Tue, 23 Aug 2011 10:02:22 +0200 Thread-Topic: Remote recording - RTC-Web client acting as SIPREC session recording client Thread-Index: AcxhanJfOVyAVK9AQb6/ifBQPZV7FQAAAV7Q Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] FW: Remote recording - RTC-Web client acting as SIPREC session recording client 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, 23 Aug 2011 08:01:17 -0000 Would SIPREC folks please note that there is considerable discussion ongoin= g on the RTCWEB mailing list concerning whether an RTC-Web client needs to = support SRC functionality. http://www.ietf.org/mail-archive/web/rtcweb/ In particular, the message below attempts to summarize the discussion to da= te. If you have views, please use the RTCWEB mailing list. John > -----Original Message----- > From: Elwell, John=20 > Sent: 23 August 2011 08:59 > To: rtcweb@ietf.org; public-webrtc@w3.org > Subject: Remote recording - RTC-Web client acting as SIPREC=20 > session recording client >=20 > There has been some discussion recently on remote recording,=20 > mixed to some extent with discussions on local recording and=20 > with mailbox, but I would like to focus on remote recording=20 > and try to summarize. >=20 > First, some background on the IETF SIPREC WG. This is=20 > specifying support for SIP-based session recording, whereby a=20 > Session Recording Client (SRC) on the path of a call=20 > (communication session) can forward media and metadata to a=20 > session recording server (SRS) or recording device. In=20 > conventional SIP terms, the SRC can exist at an endpoint of=20 > the communication session being recorded (i.e., at a SIP UA),=20 > or at a B2BUA that has access to the media as well as the=20 > signalling. Very often in a contact centre, there are=20 > mandatory requirements for recording some or all=20 > communication sessions, and often calls are routed through a=20 > B2BUA that also provides the SRC. So in this case there is no=20 > responsibility on SIP UAs to support SRC functionality, and=20 > no issues of additional bandwidth on the device's access.=20 > However, it is anticipated in SIPREC that in some deployments=20 > UA-located SRCs will be used. How a UA is organized=20 > internally to provide SRC functionality is not standardized. >=20 > So the question for RTC-Web is whether a SIP UA implemented=20 > as an RTC-Web client can provide SRC functionality, i.e.,=20 > support remote recording. An RTC-Web SIP UA is implemented by=20 > a combination of functionality running on the web server,=20 > functionality running in client side script (JS) and=20 > functionality embedded in the browser. The amount of=20 > functionality needed in the browser and needing to be exposed=20 > at the browser API in support of SRC will depend to some=20 > extent on how much core functionality goes into the browser,=20 > in particular whether the browser implements SIP or not. Some=20 > of the functions noted to date include: > - ability to take a copy of streams sent to / received from=20 > the remote party and send them, in real-time, to a remote=20 > recording device (SRS); > - possible need to mix the copied streams before sending=20 > (e.g., mix the sent and received audio streams) > - possible need to use a different codec or other parameters=20 > when sending to the SRS; > - possible need to use a different encryption/integrity=20 > context when sending to the SRS; > - possible need to insert tones / announcements into the=20 > original media path being recorded; > - possible need to support SDP enhancements for indicating=20 > media that are being recorded or preferences for which media=20 > are being recorded; > - possible need to support SIP enhancements for indicating=20 > SRC/SRS capability and recording awareness (if SIP is=20 > implemented in browser); > - possible need to support the sending of metadata to the SRS=20 > (if SIP is implemented in browser). >=20 > Clearly there would be a fairly big hurdle for browsers to=20 > support SRC functionality. But without this, RTC-Web clients=20 > would not be suitable for use in environments where remote=20 > recording is required and calls are not forced through some=20 > middlebox that provides SRC functionality. >=20 > John >=20 > John Elwell > Tel: +44 1908 817801 (office and mobile) > Email: john.elwell@siemens-enterprise.com > http://www.siemens-enterprise.com/uk/ >=20 > Siemens Enterprise Communications Limited. > Registered office: Brickhill Street, Willen Lake, Milton=20 > Keynes, MK15 0DJ. > Registered No: 5903714, England. >=20 > Siemens Enterprise Communications Limited is a Trademark=20 > Licensee of Siemens AG. > = From rmohanr@cisco.com Tue Aug 23 02:25:50 2011 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 482D621F8531 for ; Tue, 23 Aug 2011 02:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.106 X-Spam-Level: X-Spam-Status: No, score=-10.106 tagged_above=-999 required=5 tests=[AWL=0.493, 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 hWoO26N5M4IK for ; Tue, 23 Aug 2011 02:25:49 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 192EC21F8514 for ; Tue, 23 Aug 2011 02:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=4019; q=dns/txt; s=iport; t=1314091616; x=1315301216; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=3DCxht9nIvMYQM6sh+5RW8R2wTbWI4tdHUNoulv7E18=; b=I57fNIUDBesTroGXGL4EPZLVpci/Wp6ZXZfCwSnMKwxDuW9n4ZvMgLQh zHnLLUjMfzB/OD9+yoNIFvGf211h4Qj2FifjBdzOUHOogO9WN2tdOFUMr M3yzy85oOdgrXXG4L6h/rbJK7VOq7X98hJER/+IFVwL0APimVwsjyWOdI I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswAAG9xU05Io8UQ/2dsb2JhbABBDpg7j1h3gUABAQEBAgEBAQEPAR0KLgYLDAQCAQgOAwQBAQEKBhcBBgEmHwkIAQEECgEICBqHTwSYGAGfM4VpXwSHX5BQiyxA X-IronPort-AV: E=Sophos;i="4.68,268,1312156800"; d="scan'208";a="112024353" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 23 Aug 2011 09:26:54 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7N9PtrN018555; Tue, 23 Aug 2011 09:26:53 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Aug 2011 14:56:52 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Aug 2011 14:56:50 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD076C1D70@XMB-BGL-417.cisco.com> In-Reply-To: <4E527645.5060807@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Do we need a stream element? Thread-Index: Acxg4J5cmFkxIbhdS7C+PaakP+6qMgAdqYzw References: <4E3BFC29.6050001@alum.mit.edu><4E402C2F.1080103@alum.mit.edu><07465C1D981ABC41A344374066AE1A2C38B0304DA2@TLVMBX01.nice.com><2E239D6FCD033C4BAF15F386A979BF510640D1@sonusinmail02.sonusnet.com><4E525EB8.9050405@alum.mit.edu><2E239D6FCD033C4BAF15F386A979BF5106416E@sonusinmail02.sonusnet.com><4E526896.60505@alum.mit.edu> <4E527645.5060807@alum.mit.edu> From: "Ram Mohan R (rmohanr)" To: "Paul Kyzivat" , "Elwell, John" X-OriginalArrivalTime: 23 Aug 2011 09:26:52.0546 (UTC) FILETIME=[CAECE620:01CC6176] Cc: siprec@ietf.org Subject: Re: [siprec] Do we need a stream element? 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, 23 Aug 2011 09:25:50 -0000 John, Please see inline > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Monday, August 22, 2011 9:01 PM > To: Elwell, John > Cc: siprec@ietf.org > Subject: Re: [siprec] Do we need a stream element? >=20 > On 8/22/11 11:03 AM, Elwell, John wrote: > > Paul, >=20 > >> So, to take another crack at it: > >> > >> Media Stream: A data stream flowing between an evolving set of > >> senders and receivers engaged with one another in one or > more > >> communication sessions. > > [JRE] Thanks for attempting to find a definition. I think this about > captures where we are, but in my opinion it is still rather vague - > from this definition it isn't coupled to an RS, and although coupled to > one or more CSs, is not constrained to a single CS. So, as an SRC, what > criteria would I use to decide whether data streams from two CSs are > really a single Media Stream object or two Media Stream objects? > > > > In the object-orientated world, one usually tries to define an object > class to represent a tangible set of objects in some way - if you can't > define what these objects are, this might be good grounds for > questioning your choice of object class. For me, it is the same here. I > am uncomfortable with this class, simply because we are having > difficulty deciding when something is a single object of this class and > when it is several. While we work on refining the definition, I still feel it is better to have stream element in XML. I understand your point that after the discussions in IETF81 we see that most of the attributes of stream are attributes of associations and so the stream element will have only the unique ID (UUID or radix64) and the label attribute and hence it may seem a overhead. IMO it is still better to have as it provides a lot of flexibility(e.g. some of the use-cases that Paul, Partha, me pointed) and will be useful for future extensions. And I don't see any duplication of information like Charles mentioned. The XML is not going to duplicate anything which is already possible to represent in SDP Regards, Ram=20 > > John (as individual) >=20 > John, >=20 > I share your discomfort - I don't think the definition is right yet. > But I do think there is a concept there needing a definition. >=20 > Some *examples* of this: >=20 > - my "side" of the audio part of a conversation with you, > contained within a CS between you and me. >=20 > - my "side" of the audio part of a conversation with a call center > agent, contained within a CS between me and him, but also going > to the call center supervisor who is listening in. >=20 > - a mix of the audio part of a conversation between me and you, > from my perspective, including the audio I sent to you and the > audio I received from you. >=20 > - a MoH audio stream generated and sent by your phone when you put > me on hold. >=20 > - a MoH audio stream sent by an MoH server to whom I have been > transferred while on hold. A unique stream generated for me. >=20 > - a MoH multicast audio stream that was offered to me by you > when you put me on hold. That same stream has been shared by all > those put on hold by the PBX you use. >=20 > - a mixed audio stream for a conference. It contains a mix of the > loudest two participants at any one time. >=20 > In each case, the media stream exists over a period of time. > The contents of the stream can be forwarded to the SRS using one of the > RTP streams in an RS. And portions of that MS might be forwarded using > different RTP streams and/or RSs. >=20 > Without yet nailing down the definition, do you agree that there is a > well defined concept (class) here? >=20 > Thanks, > Paul > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Tue Aug 23 03:42:58 2011 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 3CD1121F8A55 for ; Tue, 23 Aug 2011 03:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.212 X-Spam-Level: X-Spam-Status: No, score=-103.212 tagged_above=-999 required=5 tests=[AWL=-0.613, 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 phXiQv-AaOD1 for ; Tue, 23 Aug 2011 03:42:57 -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 4267E21F880C for ; Tue, 23 Aug 2011 03:42:57 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 015EF1EB83F0; Tue, 23 Aug 2011 12:44:02 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 23 Aug 2011 12:44:02 +0200 From: "Elwell, John" To: Paul Kyzivat Date: Tue, 23 Aug 2011 12:44:00 +0200 Thread-Topic: [siprec] Do we need a stream element? Thread-Index: Acxg4JfRu5MjfRJER2+wcDus4wwmrQAn1V6A Message-ID: References: <4E3BFC29.6050001@alum.mit.edu><4E402C2F.1080103@alum.mit.edu><07465C1D981ABC41A344374066AE1A2C38B0304DA2@TLVMBX01.nice.com> <2E239D6FCD033C4BAF15F386A979BF510640D1@sonusinmail02.sonusnet.com> <4E525EB8.9050405@alum.mit.edu> <2E239D6FCD033C4BAF15F386A979BF5106416E@sonusinmail02.sonusnet.com> <4E526896.60505@alum.mit.edu> <4E527645.5060807@alum.mit.edu> In-Reply-To: <4E527645.5060807@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Do we need a stream element? 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, 23 Aug 2011 10:42:58 -0000 =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 > Sent: 22 August 2011 16:31 > To: Elwell, John > Cc: Ravindran Parthasarathi; Charles Eckel (eckelcu); Leon=20 > Portman; siprec@ietf.org > Subject: Re: [siprec] Do we need a stream element? >=20 > On 8/22/11 11:03 AM, Elwell, John wrote: > > Paul, >=20 > >> So, to take another crack at it: > >> > >> Media Stream: A data stream flowing between an evolving set of > >> senders and receivers engaged with one another in=20 > one or more > >> communication sessions. > > [JRE] Thanks for attempting to find a definition. I think=20 > this about captures where we are, but in my opinion it is=20 > still rather vague - from this definition it isn't coupled to=20 > an RS, and although coupled to one or more CSs, is not=20 > constrained to a single CS. So, as an SRC, what criteria=20 > would I use to decide whether data streams from two CSs are=20 > really a single Media Stream object or two Media Stream objects? > > > > In the object-orientated world, one usually tries to define=20 > an object class to represent a tangible set of objects in=20 > some way - if you can't define what these objects are, this=20 > might be good grounds for questioning your choice of object=20 > class. For me, it is the same here. I am uncomfortable with=20 > this class, simply because we are having difficulty deciding=20 > when something is a single object of this class and when it=20 > is several. > > > > John (as individual) >=20 > John, >=20 > I share your discomfort - I don't think the definition is right yet. > But I do think there is a concept there needing a definition. >=20 > Some *examples* of this: >=20 > - my "side" of the audio part of a conversation with you, > contained within a CS between you and me. >=20 > - my "side" of the audio part of a conversation with a call center > agent, contained within a CS between me and him, but also going > to the call center supervisor who is listening in. >=20 > - a mix of the audio part of a conversation between me and you, > from my perspective, including the audio I sent to you and the > audio I received from you. >=20 > - a MoH audio stream generated and sent by your phone when you put > me on hold. >=20 > - a MoH audio stream sent by an MoH server to whom I have been > transferred while on hold. A unique stream generated for me. >=20 > - a MoH multicast audio stream that was offered to me by you > when you put me on hold. That same stream has been shared by all > those put on hold by the PBX you use. >=20 > - a mixed audio stream for a conference. It contains a mix of the > loudest two participants at any one time. >=20 > In each case, the media stream exists over a period of time. > The contents of the stream can be forwarded to the SRS using=20 > one of the=20 > RTP streams in an RS. And portions of that MS might be=20 > forwarded using=20 > different RTP streams and/or RSs. >=20 > Without yet nailing down the definition, do you agree that there is a=20 > well defined concept (class) here? [JRE] Yes, each of the examples you give can be an MS. And I guess it is po= ssible you could terminate an RS and start a new RS to resume recording of = the same MS, so there might not be a 1:1 relationship between MS and RS. No= ne of these examples show why a MS can have a lifetime outside a CS - they = all sound to me like they are implicitly within the context of a CS. So it = doesn't answer my question about when a stream in the context of one CS is = considered to be the same as a stream in the context of another CS, and hen= ce the same MS object. Or putting it another way, if there is no CS in existence at a given point = in time, I would assume there is no MS in existence. So when the last CSs t= erminates, do its associated MSs die, or can they exist in a sort of hibern= ation and be revived when the next CS starts? Or in this situation, does th= e new CS have to have new MSs? John (as individual) John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. >=20 > Thanks, > Paul > = From john.elwell@siemens-enterprise.com Tue Aug 23 04:02:51 2011 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 6E31021F84F2 for ; Tue, 23 Aug 2011 04:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.207 X-Spam-Level: X-Spam-Status: No, score=-103.207 tagged_above=-999 required=5 tests=[AWL=-0.608, 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 6tHdE9KJlucN for ; Tue, 23 Aug 2011 04:02:50 -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 4B9C621F8A7B for ; Tue, 23 Aug 2011 04:02:50 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 5B73723F03EF for ; Tue, 23 Aug 2011 13:03:57 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 23 Aug 2011 13:03:57 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Tue, 23 Aug 2011 13:03:55 +0200 Thread-Topic: SRS-initiated INVITE Thread-Index: AcxdkF7Xc1PaRrtJTyKTaqWOmLsZwQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] SRS-initiated INVITE 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, 23 Aug 2011 11:02:51 -0000 (as individual) During the IETF 81 session, Andy and I agreed to propose some text for the = protocol document to cover the case of SRS-initiated INVITE in more detail.= This is our proposal: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The following is a sample call flow that shows the SRS establishing a recor= ding session towards the SRC. The most likely application of this is for p= ersistent recording, where the SRS does not need to have prior knowledge of= particular CSs that need to be recorded but simply requires to record all = CSs with certain characteristics (e.g., involving a particular user). Also = it is more likely to arise when the SRC is located at a B2BUA, rather than = at a UA, and therefore the SRS does not need to identify a particular UA as= the target of the INVITE request. UA A SRC UA B SRS | | (1) RS INVITE without SDP | | |<---------------------------------------------| | | (2) OK with SDP | | |--------------------------------------------->| | | (3) ACK with SDP | | |<---------------------------------------------| |(4)CS INVITE | | | |------------->| | | | |(5)CS INVITE | | | |---------------------->| | | | (6)OK | | | |<----------------------| | | (7)OK | | | |<-------------| | | | |(8)RS UPDATE with SDP and metadata | | |--------------------------------------------->| | | (9)OK with SDP | | |<---------------------------------------------| |(10)CS RTP | | | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|<=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| | | |(11)RS RTP | | | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D>| | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D>| |(12)CS BYE | | | |------------->| | | | |(13)CS BYE | | | |---------------------->| | | | (14) CS OK | | | |<----------------------| | | (15)OK | | | |<-------------| | | | |(16)UPDATE with SDP and metadata | = | | |--------------------------------------------->| | | (17)OK with SDP | | |<---------------------------------------------| | | | | Figure 2: Persistent Recording Call Flow, RS Established by SRS The initial INVITE request for establishing the RS (1) has a Request-URI th= at identifies the SRC and instructs the SRC what to record (e.g., all CSs i= nvolving a particular user). The SDP offer from the SRC (2) might have no m= edia or might establish inactive media in anticipation of future requiremen= ts. The first UPDATE request (8) occurs on establishment of a recordable CS. It= includes metadata describing the CS and, if necessary, includes a new SDP = offer to establish or modify media streams needed for recording that CS. The second UPDATE request (16) occurs on termination of a recordable CS. It= includes metadata indicating termination of the CS and might include a new= SDP offer changing media streams that are no longer wanted to disabled or = inactive. Because this is persistent recording, the RS would typically rema= in in place awaiting other recordable CSs. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Other places in the document will also need some changes, but I would like = first to see if we can get agreement on the general principle and on inclus= ion of this scenario in section 4. John John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. From pkyzivat@alum.mit.edu Tue Aug 23 07:20:32 2011 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 3410621F8509 for ; Tue, 23 Aug 2011 07:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 ykojCaLtj194 for ; Tue, 23 Aug 2011 07:20:31 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 2B27821F8B32 for ; Tue, 23 Aug 2011 07:20:31 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta03.westchester.pa.mail.comcast.net with comcast id Pq9e1h0031ei1Bg53qMf9Q; Tue, 23 Aug 2011 14:21:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta24.westchester.pa.mail.comcast.net with comcast id PqMM1h00B0tdiYw3kqMUzo; Tue, 23 Aug 2011 14:21:37 +0000 Message-ID: <4E53B75F.9090505@alum.mit.edu> Date: Tue, 23 Aug 2011 10:21:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Elwell, John" References: <4E3BFC29.6050001@alum.mit.edu><4E402C2F.1080103@alum.mit.edu><07465C1D981ABC41A344374066AE1A2C38B0304DA2@TLVMBX01.nice.com> <2E239D6FCD033C4BAF15F386A979BF510640D1@sonusinmail02.sonusnet.com> <4E525EB8.9050405@alum.mit.edu> <2E239D6FCD033C4BAF15F386A979BF5106416E@sonusinmail02.sonusnet.com> <4E526896.60505@alum.mit.edu> <4E527645.5060807@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Do we need a stream element? 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, 23 Aug 2011 14:20:32 -0000 On 8/23/11 6:44 AM, Elwell, John wrote: [snip] >> John, >> >> I share your discomfort - I don't think the definition is right yet. >> But I do think there is a concept there needing a definition. >> >> Some *examples* of this: >> >> - my "side" of the audio part of a conversation with you, >> contained within a CS between you and me. >> >> - my "side" of the audio part of a conversation with a call center >> agent, contained within a CS between me and him, but also going >> to the call center supervisor who is listening in. >> >> - a mix of the audio part of a conversation between me and you, >> from my perspective, including the audio I sent to you and the >> audio I received from you. >> >> - a MoH audio stream generated and sent by your phone when you put >> me on hold. >> >> - a MoH audio stream sent by an MoH server to whom I have been >> transferred while on hold. A unique stream generated for me. >> >> - a MoH multicast audio stream that was offered to me by you >> when you put me on hold. That same stream has been shared by all >> those put on hold by the PBX you use. >> >> - a mixed audio stream for a conference. It contains a mix of the >> loudest two participants at any one time. >> >> In each case, the media stream exists over a period of time. >> The contents of the stream can be forwarded to the SRS using >> one of the >> RTP streams in an RS. And portions of that MS might be >> forwarded using >> different RTP streams and/or RSs. >> >> Without yet nailing down the definition, do you agree that there is a >> well defined concept (class) here? > [JRE] Yes, each of the examples you give can be an MS. And I guess it is possible you could terminate an RS and start a new RS to resume recording of the same MS, so there might not be a 1:1 relationship between MS and RS. Yes, that is my thinking. > None of these examples show why a MS can have a lifetime outside a CS - they all sound to me like they are implicitly within the context of a CS. So it doesn't answer my question about when a stream in the context of one CS is considered to be the same as a stream in the context of another CS, and hence the same MS object. The multicast MoH stream was intended as an example of this case. It may indeed go on continuously regardless of whether there are any receivers. > Or putting it another way, if there is no CS in existence at a given point in time, I would assume there is no MS in existence. So when the last CSs terminates, do its associated MSs die, or can they exist in a sort of hibernation and be revived when the next CS starts? Or in this situation, does the new CS have to have new MSs? Based on my prior comment, I think the MS can indeed exist without any CS referencing it. Of course in that case its most likely that it will not be recorded. Treating it this way means that in a large deployment there might be hundreds of calls on hold, but the SRS could recognize that they are all receiving the same stream and so record it only once. (And yes, I do know of systems that use multicast for MoH.) Thanks, Paul From pravindran@sonusnet.com Tue Aug 23 07:34:58 2011 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 303CA21F86F6 for ; Tue, 23 Aug 2011 07:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 K7NtmSUML29S for ; Tue, 23 Aug 2011 07:34:57 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 68F1821F86CA for ; Tue, 23 Aug 2011 07:34:57 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p7NEaU0i022444; Tue, 23 Aug 2011 10:36:30 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Aug 2011 10:36:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Aug 2011 20:05:58 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51064238@sonusinmail02.sonusnet.com> In-Reply-To: <4E53B75F.9090505@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Do we need a stream element? Thread-Index: Acxhn/shwMbuRzlLRl+5E38KXR+T8QAAPIiw References: <4E3BFC29.6050001@alum.mit.edu><4E402C2F.1080103@alum.mit.edu><07465C1D981ABC41A344374066AE1A2C38B0304DA2@TLVMBX01.nice.com> <2E239D6FCD033C4BAF15F386A979BF510640D1@sonusinmail02.sonusnet.com> <4E525EB8.9050405@alum.mit.edu> <2E239D6FCD033C4BAF15F386A979BF5106416E@sonusinmail02.sonusnet.com> <4E526896.60505@alum.mit.edu> <4E527645.5060807@alum.mit.edu> <4E53B75F.9090505@alum.mit.edu> From: "Ravindran Parthasarathi" To: "Paul Kyzivat" , "Elwell, John" X-OriginalArrivalTime: 23 Aug 2011 14:36:02.0133 (UTC) FILETIME=[FB574050:01CC61A1] Cc: siprec@ietf.org Subject: Re: [siprec] Do we need a stream element? 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, 23 Aug 2011 14:34:58 -0000 John, One another example for MS exists across CS without hibernation is with customer to multiple agent transfer in call center scenario wherein customer un-mixed media stream is never stopped or put on hold till the session is terminated by customer. In this scenario, Customer (single) MS exists across CS but within any one of the CS at any given time, and the scope of this MS is within CSG. Customer MS is the single RTP stream which span across multiple CS and identified by its unique value. Thanks Partha >-----Original Message----- >From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >Sent: Tuesday, August 23, 2011 7:51 PM >To: Elwell, John >Cc: Ravindran Parthasarathi; Charles Eckel (eckelcu); Leon Portman; >siprec@ietf.org >Subject: Re: [siprec] Do we need a stream element? > >On 8/23/11 6:44 AM, Elwell, John wrote: >[snip] >>> John, >>> >>> I share your discomfort - I don't think the definition is right yet. >>> But I do think there is a concept there needing a definition. >>> >>> Some *examples* of this: >>> >>> - my "side" of the audio part of a conversation with you, >>> contained within a CS between you and me. >>> >>> - my "side" of the audio part of a conversation with a call center >>> agent, contained within a CS between me and him, but also going >>> to the call center supervisor who is listening in. >>> >>> - a mix of the audio part of a conversation between me and you, >>> from my perspective, including the audio I sent to you and the >>> audio I received from you. >>> >>> - a MoH audio stream generated and sent by your phone when you put >>> me on hold. >>> >>> - a MoH audio stream sent by an MoH server to whom I have been >>> transferred while on hold. A unique stream generated for me. >>> >>> - a MoH multicast audio stream that was offered to me by you >>> when you put me on hold. That same stream has been shared by all >>> those put on hold by the PBX you use. >>> >>> - a mixed audio stream for a conference. It contains a mix of the >>> loudest two participants at any one time. >>> >>> In each case, the media stream exists over a period of time. >>> The contents of the stream can be forwarded to the SRS using >>> one of the >>> RTP streams in an RS. And portions of that MS might be >>> forwarded using >>> different RTP streams and/or RSs. >>> >>> Without yet nailing down the definition, do you agree that there is a >>> well defined concept (class) here? >> [JRE] Yes, each of the examples you give can be an MS. And I guess it >is possible you could terminate an RS and start a new RS to resume >recording of the same MS, so there might not be a 1:1 relationship >between MS and RS. > >Yes, that is my thinking. > >> None of these examples show why a MS can have a lifetime outside a CS >- they all sound to me like they are implicitly within the context of a >CS. So it doesn't answer my question about when a stream in the context >of one CS is considered to be the same as a stream in the context of >another CS, and hence the same MS object. > >The multicast MoH stream was intended as an example of this case. >It may indeed go on continuously regardless of whether there are any >receivers. > >> Or putting it another way, if there is no CS in existence at a given >point in time, I would assume there is no MS in existence. So when the >last CSs terminates, do its associated MSs die, or can they exist in a >sort of hibernation and be revived when the next CS starts? Or in this >situation, does the new CS have to have new MSs? > >Based on my prior comment, I think the MS can indeed exist without any >CS referencing it. Of course in that case its most likely that it will >not be recorded. > >Treating it this way means that in a large deployment there might be >hundreds of calls on hold, but the SRS could recognize that they are all >receiving the same stream and so record it only once. > >(And yes, I do know of systems that use multicast for MoH.) > > Thanks, > Paul From pkyzivat@alum.mit.edu Tue Aug 23 07:54:17 2011 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 9D3C621F89CC for ; Tue, 23 Aug 2011 07:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 OXBn4YpzXtZy for ; Tue, 23 Aug 2011 07:54:16 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0B521F8880 for ; Tue, 23 Aug 2011 07:54:16 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta06.westchester.pa.mail.comcast.net with comcast id PquZ1h0011YDfWL56qvRNV; Tue, 23 Aug 2011 14:55:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta20.westchester.pa.mail.comcast.net with comcast id PqvK1h0180tdiYw3gqvPNV; Tue, 23 Aug 2011 14:55:24 +0000 Message-ID: <4E53BF55.3010309@alum.mit.edu> Date: Tue, 23 Aug 2011 10:55:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: siprec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] SRS-initiated INVITE 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, 23 Aug 2011 14:54:17 -0000 IIUC, the essential feature of this flow is that the R-URI from SRS to SRC in some way encodes the criteria for what calls the SRC should record. I guess you are assuming that the manner of that encoding is unstandardized, and hence requires a side agreement between the SRC and SRS. Or else it requires that the SRS be configurable to establish an RS to an arbitrary URI, and that the administrator is aware of the specific URI encoding required by the SRC to achieve the intended effect. While that is a bit of a stretch, I don't have any particular problem with including such an example. But this doesn't ensure that any SRC actually has this capability. Thanks, Paul On 8/23/11 7:03 AM, Elwell, John wrote: > (as individual) > > During the IETF 81 session, Andy and I agreed to propose some text for the protocol document to cover the case of SRS-initiated INVITE in more detail. This is our proposal: > > ======================= > The following is a sample call flow that shows the SRS establishing a recording session towards the SRC. The most likely application of this is for persistent recording, where the SRS does not need to have prior knowledge of particular CSs that need to be recorded but simply requires to record all CSs with certain characteristics (e.g., involving a particular user). Also it is more likely to arise when the SRC is located at a B2BUA, rather than at a UA, and therefore the SRS does not need to identify a particular UA as the target of the INVITE request. > > > UA A SRC UA B SRS > | | (1) RS INVITE without SDP | > | |<---------------------------------------------| > | | (2) OK with SDP | > | |--------------------------------------------->| > | | (3) ACK with SDP | > | |<---------------------------------------------| > |(4)CS INVITE | | | > |------------->| | | > | |(5)CS INVITE | | > | |---------------------->| | > | | (6)OK | | > | |<----------------------| | > | (7)OK | | | > |<-------------| | | > | |(8)RS UPDATE with SDP and metadata | > | |--------------------------------------------->| > | | (9)OK with SDP | > | |<---------------------------------------------| > |(10)CS RTP | | | > |=============>|======================>| | > |<=============|<======================| | > | |(11)RS RTP | | > | |=============================================>| > | |=============================================>| > |(12)CS BYE | | | > |------------->| | | > | |(13)CS BYE | | > | |---------------------->| | > | | (14) CS OK | | > | |<----------------------| | > | (15)OK | | | > |<-------------| | | > | |(16)UPDATE with SDP and metadata | | > | |--------------------------------------------->| > | | (17)OK with SDP | > | |<---------------------------------------------| > | | | | > > Figure 2: Persistent Recording Call Flow, RS Established by SRS > > The initial INVITE request for establishing the RS (1) has a Request-URI that identifies the SRC and instructs the SRC what to record (e.g., all CSs involving a particular user). The SDP offer from the SRC (2) might have no media or might establish inactive media in anticipation of future requirements. > > The first UPDATE request (8) occurs on establishment of a recordable CS. It includes metadata describing the CS and, if necessary, includes a new SDP offer to establish or modify media streams needed for recording that CS. > > The second UPDATE request (16) occurs on termination of a recordable CS. It includes metadata indicating termination of the CS and might include a new SDP offer changing media streams that are no longer wanted to disabled or inactive. Because this is persistent recording, the RS would typically remain in place awaiting other recordable CSs. > ================================= > > Other places in the document will also need some changes, but I would like first to see if we can get agreement on the general principle and on inclusion of this scenario in section 4. > > John > > > John Elwell > Tel: +44 1908 817801 (office and mobile) > Email: john.elwell@siemens-enterprise.com > http://www.siemens-enterprise.com/uk/ > > Siemens Enterprise Communications Limited. > Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. > Registered No: 5903714, England. > > Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG. > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From john.elwell@siemens-enterprise.com Tue Aug 23 08:48:47 2011 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 C5C3821F87E2 for ; Tue, 23 Aug 2011 08:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.198 X-Spam-Level: X-Spam-Status: No, score=-103.198 tagged_above=-999 required=5 tests=[AWL=-0.599, 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 Yjbb6SyxdCFc for ; Tue, 23 Aug 2011 08:48:47 -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 7E2B021F87C2 for ; Tue, 23 Aug 2011 08:48:46 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 4604723F04E7; Tue, 23 Aug 2011 17:49:54 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 23 Aug 2011 17:49:54 +0200 From: "Elwell, John" To: Paul Kyzivat Date: Tue, 23 Aug 2011 17:49:52 +0200 Thread-Topic: [siprec] Do we need a stream element? Thread-Index: Acxhn/lfy6dNyIaSQRa2IBM89xEG3wACzGNg Message-ID: References: <4E3BFC29.6050001@alum.mit.edu><4E402C2F.1080103@alum.mit.edu><07465C1D981ABC41A344374066AE1A2C38B0304DA2@TLVMBX01.nice.com> <2E239D6FCD033C4BAF15F386A979BF510640D1@sonusinmail02.sonusnet.com> <4E525EB8.9050405@alum.mit.edu> <2E239D6FCD033C4BAF15F386A979BF5106416E@sonusinmail02.sonusnet.com> <4E526896.60505@alum.mit.edu> <4E527645.5060807@alum.mit.edu> <4E53B75F.9090505@alum.mit.edu> In-Reply-To: <4E53B75F.9090505@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Do we need a stream element? 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, 23 Aug 2011 15:48:47 -0000 =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 > Sent: 23 August 2011 15:21 > To: Elwell, John > Cc: Ravindran Parthasarathi; Charles Eckel (eckelcu); Leon=20 > Portman; siprec@ietf.org > Subject: Re: [siprec] Do we need a stream element? >=20 > On 8/23/11 6:44 AM, Elwell, John wrote: > [snip] > >> John, > >> > >> I share your discomfort - I don't think the definition is=20 > right yet. > >> But I do think there is a concept there needing a definition. > >> > >> Some *examples* of this: > >> > >> - my "side" of the audio part of a conversation with you, > >> contained within a CS between you and me. > >> > >> - my "side" of the audio part of a conversation with a call center > >> agent, contained within a CS between me and him, but also going > >> to the call center supervisor who is listening in. > >> > >> - a mix of the audio part of a conversation between me and you, > >> from my perspective, including the audio I sent to you and the > >> audio I received from you. > >> > >> - a MoH audio stream generated and sent by your phone when you put > >> me on hold. > >> > >> - a MoH audio stream sent by an MoH server to whom I have been > >> transferred while on hold. A unique stream generated for me. > >> > >> - a MoH multicast audio stream that was offered to me by you > >> when you put me on hold. That same stream has been=20 > shared by all > >> those put on hold by the PBX you use. > >> > >> - a mixed audio stream for a conference. It contains a mix of the > >> loudest two participants at any one time. > >> > >> In each case, the media stream exists over a period of time. > >> The contents of the stream can be forwarded to the SRS using > >> one of the > >> RTP streams in an RS. And portions of that MS might be > >> forwarded using > >> different RTP streams and/or RSs. > >> > >> Without yet nailing down the definition, do you agree that=20 > there is a > >> well defined concept (class) here? > > [JRE] Yes, each of the examples you give can be an MS. And=20 > I guess it is possible you could terminate an RS and start a=20 > new RS to resume recording of the same MS, so there might not=20 > be a 1:1 relationship between MS and RS. >=20 > Yes, that is my thinking. >=20 > > None of these examples show why a MS can have a lifetime=20 > outside a CS - they all sound to me like they are implicitly=20 > within the context of a CS. So it doesn't answer my question=20 > about when a stream in the context of one CS is considered to=20 > be the same as a stream in the context of another CS, and=20 > hence the same MS object. >=20 > The multicast MoH stream was intended as an example of this case. > It may indeed go on continuously regardless of whether there are any=20 > receivers. [JRE] OK, I understand now, but is the stream really of interest while ther= e are no receivers, and when a receiver does appear again and it needs to b= e recorded again, what benefit arises from saying it is the same stream, as= opposed to some new stream? >=20 > > Or putting it another way, if there is no CS in existence=20 > at a given point in time, I would assume there is no MS in=20 > existence. So when the last CSs terminates, do its associated=20 > MSs die, or can they exist in a sort of hibernation and be=20 > revived when the next CS starts? Or in this situation, does=20 > the new CS have to have new MSs? >=20 > Based on my prior comment, I think the MS can indeed exist=20 > without any=20 > CS referencing it. Of course in that case its most likely=20 > that it will=20 > not be recorded. >=20 > Treating it this way means that in a large deployment there might be=20 > hundreds of calls on hold, but the SRS could recognize that=20 > they are all=20 > receiving the same stream and so record it only once. [JRE] This requires the SRC to recognize that two or more participants in d= ifferent CSs are really receiving the same stream. I don't know how often t= hat will occur in practice. But then consider what happens at the SRS - doe= s it record the stream only once, and as part of which CS recording? It wou= ld need to avoid the problem that, but deleting one CS recording, it also d= eletes a stream that other CS recordings depend on. On the other hand, if t= he stream is recorded independently of any CS recording, then what would tr= igger its deletion when all CS recordings that use it have been deleted (ga= rbage collection)? I can see that having a separate identifier for a stream could have benefit= s, but they seem like corner cases to me. It is a question of whether the W= G feels the added overhead is justified. John (as individual) John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. >=20 > (And yes, I do know of systems that use multicast for MoH.) > >=20 > Thanks, > Paul > = From john.elwell@siemens-enterprise.com Tue Aug 23 12:50:06 2011 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 94DB421F8CA1 for ; Tue, 23 Aug 2011 12:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.194 X-Spam-Level: X-Spam-Status: No, score=-103.194 tagged_above=-999 required=5 tests=[AWL=-0.595, 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 hHZWVddpW6Cy for ; Tue, 23 Aug 2011 12:50:05 -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 62EF721F8C9E for ; Tue, 23 Aug 2011 12:50:05 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id B673E1EB8456; Tue, 23 Aug 2011 21:51:10 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 23 Aug 2011 21:51:10 +0200 From: "Elwell, John" To: Paul Kyzivat , "siprec@ietf.org" Date: Tue, 23 Aug 2011 21:51:09 +0200 Thread-Topic: [siprec] SRS-initiated INVITE Thread-Index: AcxhpLMuIJ9FkXicQtaeTNyHx7+jIwAKSxLA Message-ID: References: <4E53BF55.3010309@alum.mit.edu> In-Reply-To: <4E53BF55.3010309@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] SRS-initiated INVITE 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, 23 Aug 2011 19:50:06 -0000 =20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 23 August 2011 15:55 > To: siprec@ietf.org > Subject: Re: [siprec] SRS-initiated INVITE >=20 > IIUC, the essential feature of this flow is that the R-URI=20 > from SRS to=20 > SRC in some way encodes the criteria for what calls the SRC=20 > should record. >=20 > I guess you are assuming that the manner of that encoding is=20 > unstandardized, and hence requires a side agreement between=20 > the SRC and=20 > SRS. Or else it requires that the SRS be configurable to=20 > establish an RS=20 > to an arbitrary URI, and that the administrator is aware of=20 > the specific=20 > URI encoding required by the SRC to achieve the intended effect. >=20 > While that is a bit of a stretch, I don't have any particular problem=20 > with including such an example. But this doesn't ensure that any SRC=20 > actually has this capability. [JRE] Quite so. But if the SRC has a URI that can be used and the SRS is co= nfigured with that URI, it should work. John >=20 > Thanks, > Paul >=20 > On 8/23/11 7:03 AM, Elwell, John wrote: > > (as individual) > > > > During the IETF 81 session, Andy and I agreed to propose=20 > some text for the protocol document to cover the case of=20 > SRS-initiated INVITE in more detail. This is our proposal: > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The following is a sample call flow that shows the SRS=20 > establishing a recording session towards the SRC. The most=20 > likely application of this is for persistent recording, where=20 > the SRS does not need to have prior knowledge of particular=20 > CSs that need to be recorded but simply requires to record=20 > all CSs with certain characteristics (e.g., involving a=20 > particular user). Also it is more likely to arise when the=20 > SRC is located at a B2BUA, rather than at a UA, and therefore=20 > the SRS does not need to identify a particular UA as the=20 > target of the INVITE request. > > > > > > UA A SRC UA B =20 > SRS > > | | (1) RS INVITE without SDP | > > | |<---------------------------------------------| > > | | (2) OK with SDP | > > | |--------------------------------------------->| > > | | (3) ACK with SDP | > > | |<---------------------------------------------| > > |(4)CS INVITE | | | > > |------------->| | | > > | |(5)CS INVITE | | > > | |---------------------->| | > > | | (6)OK | | > > | |<----------------------| | > > | (7)OK | | | > > |<-------------| | | > > | |(8)RS UPDATE with SDP and metadata | > > | |--------------------------------------------->| > > | | (9)OK with SDP | > > | |<---------------------------------------------| > > |(10)CS RTP | | | > > |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | > > |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|<=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| | > > | |(11)RS RTP | | > > | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D>| > > | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D>| > > |(12)CS BYE | | | > > |------------->| | | > > | |(13)CS BYE | | > > | |---------------------->| | > > | | (14) CS OK | | > > | |<----------------------| | > > | (15)OK | | | > > |<-------------| | | > > | |(16)UPDATE with SDP and metadata =20 > | | > > | |--------------------------------------------->| > > | | (17)OK with SDP | > > | |<---------------------------------------------| > > | | | | > > > > Figure 2: Persistent Recording Call Flow, RS=20 > Established by SRS > > > > The initial INVITE request for establishing the RS (1) has=20 > a Request-URI that identifies the SRC and instructs the SRC=20 > what to record (e.g., all CSs involving a particular user).=20 > The SDP offer from the SRC (2) might have no media or might=20 > establish inactive media in anticipation of future requirements. > > > > The first UPDATE request (8) occurs on establishment of a=20 > recordable CS. It includes metadata describing the CS and, if=20 > necessary, includes a new SDP offer to establish or modify=20 > media streams needed for recording that CS. > > > > The second UPDATE request (16) occurs on termination of a=20 > recordable CS. It includes metadata indicating termination of=20 > the CS and might include a new SDP offer changing media=20 > streams that are no longer wanted to disabled or inactive.=20 > Because this is persistent recording, the RS would typically=20 > remain in place awaiting other recordable CSs. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Other places in the document will also need some changes,=20 > but I would like first to see if we can get agreement on the=20 > general principle and on inclusion of this scenario in section 4. > > > > John > > > > > > John Elwell > > Tel: +44 1908 817801 (office and mobile) > > Email: john.elwell@siemens-enterprise.com > > http://www.siemens-enterprise.com/uk/ > > > > Siemens Enterprise Communications Limited. > > Registered office: Brickhill Street, Willen Lake, Milton=20 > Keynes, MK15 0DJ. > > Registered No: 5903714, England. > > > > Siemens Enterprise Communications Limited is a Trademark=20 > Licensee of Siemens AG. > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From eckelcu@cisco.com Tue Aug 23 13:48:35 2011 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 B882D21F8CDF for ; Tue, 23 Aug 2011 13:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.805 X-Spam-Level: X-Spam-Status: No, score=-2.805 tagged_above=-999 required=5 tests=[AWL=-0.206, 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 s2P5cEy6shaz for ; Tue, 23 Aug 2011 13:48:35 -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 BAACF21F8CD2 for ; Tue, 23 Aug 2011 13:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=7011; q=dns/txt; s=iport; t=1314132583; x=1315342183; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=NVgVxE8idkUtdF+PyP2//AbbsEk4iFVp+CS+xlLVfVk=; b=YwhPp4B9K5zhzFVkzTSNqaoKl7aJJnk9uwHyRaVmX7ZQCnMSB3SQ4gEC sYSWzmTP+XJpjkTdJvHMP3kUFfQ12tjEkJJUmoUYXvH2ONRraRcXzKmUa ZxSrEA3nua2tbcWd6hMtEJxmGiBXFNGJeOO56XqQdXhFY6zIQgO2w4IuK 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMAAD0SVE6rRDoH/2dsb2JhbABCDpgFj1J3gUABAQEBAxIBHQouCgcMBAIBCBEEAQEBCgYXAQYBRQkIAQEEAQkJCBqHU513AZ8/hWlfBIdhkE6LLFg X-IronPort-AV: E=Sophos;i="4.68,271,1312156800"; d="scan'208";a="15832918" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-9.cisco.com with ESMTP; 23 Aug 2011 20:49:42 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7NKngIV007129; Tue, 23 Aug 2011 20:49:42 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); Tue, 23 Aug 2011 13:49:25 -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: Tue, 23 Aug 2011 13:49:22 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Do we need a stream element? Thread-Index: Acxhn/lfy6dNyIaSQRa2IBM89xEG3wACzGNgAAovh2A= References: <4E3BFC29.6050001@alum.mit.edu><4E402C2F.1080103@alum.mit.edu><07465C1D981ABC41A344374066AE1A2C38B0304DA2@TLVMBX01.nice.com> <2E239D6FCD033C4BAF15F386A979BF510640D1@sonusinmail02.sonusnet.com> <4E525EB8.9050405@alum.mit.edu> <2E239D6FCD033C4BAF15F386A979BF5106416E@sonusinmail02.sonusnet.com> <4E526896.60505@alum.mit.edu> <4E527645.5060807@alum.mit.edu> <4E53B75F.9090505@alum.mit.edu> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , "Paul Kyzivat" X-OriginalArrivalTime: 23 Aug 2011 20:49:25.0152 (UTC) FILETIME=[2494AA00:01CC61D6] Cc: siprec@ietf.org Subject: Re: [siprec] Do we need a stream element? 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, 23 Aug 2011 20:48:35 -0000 Hi John, >From all the examples, I do not yet see much value. The only case in which I have seen some value is the case of an SRS that is handling many recordings being able to detect that it is receiving multiple copies of the same stream and optimizing to record only a single instance of it (e.g. the multicast MoH case). For this specific case, it may be better to add a mechanism to not record it at all. My thought is SRC implementations may be smart enough to not include such streams in the RS. But that is outside the scope of SIPREC. And in general, I am not sure how likely it is that the SRCs will recognize this stream as being the same, and use the same ID for it. Using the same MS to represent the media from a participant before and after a transfer does not seem necessary to me. As long as the media before and after the transfer is associated with the same participant, that seems sufficient to me. My main hesitation with saying it is not necessary is that several people seem to be making arguments for why it is necessary. My question to them is, are you pointing out hypothetical use cases that you agree are edge cases that can be ignored for now, or are these use cases really of great interest to you. Cheers, Charles=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Tuesday, August 23, 2011 8:50 AM > To: Paul Kyzivat > Cc: Ravindran Parthasarathi; Charles Eckel (eckelcu); Leon Portman; siprec@ietf.org > Subject: RE: [siprec] Do we need a stream element? >=20 >=20 >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > Sent: 23 August 2011 15:21 > > To: Elwell, John > > Cc: Ravindran Parthasarathi; Charles Eckel (eckelcu); Leon > > Portman; siprec@ietf.org > > Subject: Re: [siprec] Do we need a stream element? > > > > On 8/23/11 6:44 AM, Elwell, John wrote: > > [snip] > > >> John, > > >> > > >> I share your discomfort - I don't think the definition is > > right yet. > > >> But I do think there is a concept there needing a definition. > > >> > > >> Some *examples* of this: > > >> > > >> - my "side" of the audio part of a conversation with you, > > >> contained within a CS between you and me. > > >> > > >> - my "side" of the audio part of a conversation with a call center > > >> agent, contained within a CS between me and him, but also going > > >> to the call center supervisor who is listening in. > > >> > > >> - a mix of the audio part of a conversation between me and you, > > >> from my perspective, including the audio I sent to you and the > > >> audio I received from you. > > >> > > >> - a MoH audio stream generated and sent by your phone when you put > > >> me on hold. > > >> > > >> - a MoH audio stream sent by an MoH server to whom I have been > > >> transferred while on hold. A unique stream generated for me. > > >> > > >> - a MoH multicast audio stream that was offered to me by you > > >> when you put me on hold. That same stream has been > > shared by all > > >> those put on hold by the PBX you use. > > >> > > >> - a mixed audio stream for a conference. It contains a mix of the > > >> loudest two participants at any one time. > > >> > > >> In each case, the media stream exists over a period of time. > > >> The contents of the stream can be forwarded to the SRS using > > >> one of the > > >> RTP streams in an RS. And portions of that MS might be > > >> forwarded using > > >> different RTP streams and/or RSs. > > >> > > >> Without yet nailing down the definition, do you agree that > > there is a > > >> well defined concept (class) here? > > > [JRE] Yes, each of the examples you give can be an MS. And > > I guess it is possible you could terminate an RS and start a > > new RS to resume recording of the same MS, so there might not > > be a 1:1 relationship between MS and RS. > > > > Yes, that is my thinking. > > > > > None of these examples show why a MS can have a lifetime > > outside a CS - they all sound to me like they are implicitly > > within the context of a CS. So it doesn't answer my question > > about when a stream in the context of one CS is considered to > > be the same as a stream in the context of another CS, and > > hence the same MS object. > > > > The multicast MoH stream was intended as an example of this case. > > It may indeed go on continuously regardless of whether there are any > > receivers. > [JRE] OK, I understand now, but is the stream really of interest while there are no receivers, and > when a receiver does appear again and it needs to be recorded again, what benefit arises from saying > it is the same stream, as opposed to some new stream? >=20 > > > > > Or putting it another way, if there is no CS in existence > > at a given point in time, I would assume there is no MS in > > existence. So when the last CSs terminates, do its associated > > MSs die, or can they exist in a sort of hibernation and be > > revived when the next CS starts? Or in this situation, does > > the new CS have to have new MSs? > > > > Based on my prior comment, I think the MS can indeed exist > > without any > > CS referencing it. Of course in that case its most likely > > that it will > > not be recorded. > > > > Treating it this way means that in a large deployment there might be > > hundreds of calls on hold, but the SRS could recognize that > > they are all > > receiving the same stream and so record it only once. > [JRE] This requires the SRC to recognize that two or more participants in different CSs are really > receiving the same stream. I don't know how often that will occur in practice. But then consider what > happens at the SRS - does it record the stream only once, and as part of which CS recording? It would > need to avoid the problem that, but deleting one CS recording, it also deletes a stream that other CS > recordings depend on. On the other hand, if the stream is recorded independently of any CS recording, > then what would trigger its deletion when all CS recordings that use it have been deleted (garbage > collection)? >=20 > I can see that having a separate identifier for a stream could have benefits, but they seem like > corner cases to me. It is a question of whether the WG feels the added overhead is justified. >=20 > John (as individual) >=20 >=20 > John Elwell > Tel: +44 1908 817801 (office and mobile) > Email: john.elwell@siemens-enterprise.com > http://www.siemens-enterprise.com/uk/ >=20 > Siemens Enterprise Communications Limited. > Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. > Registered No: 5903714, England. >=20 > Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG. >=20 > > > > (And yes, I do know of systems that use multicast for MoH.) > > > > > > Thanks, > > Paul > > From eckelcu@cisco.com Tue Aug 23 14:04:39 2011 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 E7FC421F8D3A for ; Tue, 23 Aug 2011 14:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[AWL=-0.202, 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 oSIVOcBs7zBP for ; Tue, 23 Aug 2011 14:04:39 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id CB5D021F8D37 for ; Tue, 23 Aug 2011 14:04:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=7766; q=dns/txt; s=iport; t=1314133547; x=1315343147; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Y5cFUFPpQ68JMri294bf2kNPiSxrftgK9o6VdQg0iFo=; b=nLOVLOYtRZCbvYbdu8GgUMJZj1ZjuZ13Xcb1v64M94eqz8aa4QnsXgSB +dmiuna602fpZLH7wheoyh2CQmxw1NfDxZpeUyb+ggr2k13Z8w75Yppbz 69OYfKtcCvs41gtdBREjiqqiXb98sEjx8gguXvBXCjGkLZJYoV1o0Rbos k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMAACMVVE6rRDoG/2dsb2JhbAA4Cg6YBY9Sd4FAAQEBAQMBAQEPARQJCi4GFwQCAQgRBAEBAQoGFwEGASYfCQgBAQQBEggah1OdfQGfQ4MngkJfBIdhkE6LLFg X-IronPort-AV: E=Sophos;i="4.68,271,1312156800"; d="scan'208";a="15831070" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-3.cisco.com with ESMTP; 23 Aug 2011 21:05:46 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7NL5iIQ002527; Tue, 23 Aug 2011 21:05:45 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); Tue, 23 Aug 2011 14:05:44 -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: Tue, 23 Aug 2011 14:05:42 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] SRS-initiated INVITE Thread-Index: AcxhpLMuIJ9FkXicQtaeTNyHx7+jIwAKSxLAAAJz2YA= References: <4E53BF55.3010309@alum.mit.edu> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , "Paul Kyzivat" , X-OriginalArrivalTime: 23 Aug 2011 21:05:44.0039 (UTC) FILETIME=[6C0AF770:01CC61D8] Subject: Re: [siprec] SRS-initiated INVITE 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, 23 Aug 2011 21:04:40 -0000 Hi John, I was envisioning a use case in which the INVITE from the SRS to the SRC contains a Request-URI for a call that is to be joined for the purpose of recording (e.g. a conference call). The SRS may include SDP as well. The SRC could initiate the CS INVITE in this case.=20 I'd like to hear what others think about making your proposal more generic to accommodate that as well. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Tuesday, August 23, 2011 12:51 PM > To: Paul Kyzivat; siprec@ietf.org > Subject: Re: [siprec] SRS-initiated INVITE >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > Sent: 23 August 2011 15:55 > > To: siprec@ietf.org > > Subject: Re: [siprec] SRS-initiated INVITE > > > > IIUC, the essential feature of this flow is that the R-URI > > from SRS to > > SRC in some way encodes the criteria for what calls the SRC > > should record. > > > > I guess you are assuming that the manner of that encoding is > > unstandardized, and hence requires a side agreement between > > the SRC and > > SRS. Or else it requires that the SRS be configurable to > > establish an RS > > to an arbitrary URI, and that the administrator is aware of > > the specific > > URI encoding required by the SRC to achieve the intended effect. > > > > While that is a bit of a stretch, I don't have any particular problem > > with including such an example. But this doesn't ensure that any SRC > > actually has this capability. > [JRE] Quite so. But if the SRC has a URI that can be used and the SRS is configured with that URI, it > should work. >=20 > John >=20 >=20 > > > > Thanks, > > Paul > > > > On 8/23/11 7:03 AM, Elwell, John wrote: > > > (as individual) > > > > > > During the IETF 81 session, Andy and I agreed to propose > > some text for the protocol document to cover the case of > > SRS-initiated INVITE in more detail. This is our proposal: > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > The following is a sample call flow that shows the SRS > > establishing a recording session towards the SRC. The most > > likely application of this is for persistent recording, where > > the SRS does not need to have prior knowledge of particular > > CSs that need to be recorded but simply requires to record > > all CSs with certain characteristics (e.g., involving a > > particular user). Also it is more likely to arise when the > > SRC is located at a B2BUA, rather than at a UA, and therefore > > the SRS does not need to identify a particular UA as the > > target of the INVITE request. > > > > > > > > > UA A SRC UA B > > SRS > > > | | (1) RS INVITE without SDP | > > > | |<---------------------------------------------| > > > | | (2) OK with SDP | > > > | |--------------------------------------------->| > > > | | (3) ACK with SDP | > > > | |<---------------------------------------------| > > > |(4)CS INVITE | | | > > > |------------->| | | > > > | |(5)CS INVITE | | > > > | |---------------------->| | > > > | | (6)OK | | > > > | |<----------------------| | > > > | (7)OK | | | > > > |<-------------| | | > > > | |(8)RS UPDATE with SDP and metadata | > > > | |--------------------------------------------->| > > > | | (9)OK with SDP | > > > | |<---------------------------------------------| > > > |(10)CS RTP | | | > > > = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | > > > = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| | > > > | |(11)RS RTP | | > > > | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > > | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > > |(12)CS BYE | | | > > > |------------->| | | > > > | |(13)CS BYE | | > > > | |---------------------->| | > > > | | (14) CS OK | | > > > | |<----------------------| | > > > | (15)OK | | | > > > |<-------------| | | > > > | |(16)UPDATE with SDP and metadata > > | | > > > | |--------------------------------------------->| > > > | | (17)OK with SDP | > > > | |<---------------------------------------------| > > > | | | | > > > > > > Figure 2: Persistent Recording Call Flow, RS > > Established by SRS > > > > > > The initial INVITE request for establishing the RS (1) has > > a Request-URI that identifies the SRC and instructs the SRC > > what to record (e.g., all CSs involving a particular user). > > The SDP offer from the SRC (2) might have no media or might > > establish inactive media in anticipation of future requirements. > > > > > > The first UPDATE request (8) occurs on establishment of a > > recordable CS. It includes metadata describing the CS and, if > > necessary, includes a new SDP offer to establish or modify > > media streams needed for recording that CS. > > > > > > The second UPDATE request (16) occurs on termination of a > > recordable CS. It includes metadata indicating termination of > > the CS and might include a new SDP offer changing media > > streams that are no longer wanted to disabled or inactive. > > Because this is persistent recording, the RS would typically > > remain in place awaiting other recordable CSs. > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > > > > Other places in the document will also need some changes, > > but I would like first to see if we can get agreement on the > > general principle and on inclusion of this scenario in section 4. > > > > > > John > > > > > > > > > John Elwell > > > Tel: +44 1908 817801 (office and mobile) > > > Email: john.elwell@siemens-enterprise.com > > > http://www.siemens-enterprise.com/uk/ > > > > > > Siemens Enterprise Communications Limited. > > > Registered office: Brickhill Street, Willen Lake, Milton > > Keynes, MK15 0DJ. > > > Registered No: 5903714, England. > > > > > > Siemens Enterprise Communications Limited is a Trademark > > Licensee of Siemens AG. > > > > > > > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Tue Aug 23 14:08:18 2011 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 B8CA521F8D3C for ; Tue, 23 Aug 2011 14:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[AWL=-0.198, 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 qh0XTELXinlx for ; Tue, 23 Aug 2011 14:08:18 -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 14D7F21F8D1C for ; Tue, 23 Aug 2011 14:08:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2042; q=dns/txt; s=iport; t=1314133767; x=1315343367; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=qN+CWXSWKscPBAekyDuvUdKb3Sp7PeqBom1D8pVKSnI=; b=NEkYhJSuZhV6uB7HwRAxg5G8kuQBXRJOz46ang7NwfE6WuvGXlZytGKH lpqDAOL8cGvPzhQ3gSVbtI9bnI7PXsUgKYLyAfkl0C0TFgYqF9Z/YM/04 40NDShzJckWfjZXwEoTqQucHnrMRV3izg8bliKIk4LZBFNldzmRpcY2bi s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQAANYWVE6rRDoJ/2dsb2JhbABChEyTR45mbHeBQAEBAQEDAQEBDwEQDQQ6CwwEAgEIEQQBAQMCBgYXAQICAgEBJR8JCAEBBAESCBqHU51xAY03kgyBLIQMMV8Eh2GQToRihyI X-IronPort-AV: E=Sophos;i="4.68,271,1312156800"; d="scan'208";a="15838610" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-9.cisco.com with ESMTP; 23 Aug 2011 21:09:20 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p7NL9KdA001973; Tue, 23 Aug 2011 21:09:20 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Aug 2011 14:09:20 -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: Tue, 23 Aug 2011 14:09:19 -0700 Message-ID: In-Reply-To: <084.53cdc48fc0a5a2dadeb3fd8d93617fb2@trac.tools.ietf.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] #68: Start/stop time for Recording Session Thread-Index: Acxg98LIkhXHYrFoSL61/QGes7mOXAA4QefA References: <075.db8ff04b7cbf099d401d476dc3008b5f@trac.tools.ietf.org> <084.53cdc48fc0a5a2dadeb3fd8d93617fb2@trac.tools.ietf.org> From: "Charles Eckel (eckelcu)" To: "siprec issue tracker" , "Ram Mohan R (rmohanr)" , "Parthasarathi R (partr)" X-OriginalArrivalTime: 23 Aug 2011 21:09:20.0535 (UTC) FILETIME=[ED15A270:01CC61D8] Cc: siprec@ietf.org Subject: Re: [siprec] #68: Start/stop time for Recording Session X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 21:08:18 -0000 SSBoYWQgaG9wZWQgdGhlIHJlc29sdXRpb24gY291bGQgc3RhdGUgd2hhdCB3YXMgZGVjaWRlZCBh bmQgd2h5IHNvIHRoYXQgd2UgZG8gbm90IGNpcmNsZSBiYWNrIG9uIHRoaXMgYWdhaW4uIEkgYWxy ZWFkeSBmb3Jnb3Qgd2hhdCB3ZSBkZWNpZGVkIDopDQoNCkNoZWVycywNCkNoYXJsZXMNCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzaXByZWMtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOnNpcHJlYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Ygc2lwcmVjIGlz c3VlIHRyYWNrZXINCj4gU2VudDogTW9uZGF5LCBBdWd1c3QgMjIsIDIwMTEgMTE6MTcgQU0NCj4g VG86IFJhbSBNb2hhbiBSIChybW9oYW5yKTsgUGFydGhhc2FyYXRoaSBSIChwYXJ0cikNCj4gQ2M6 IHNpcHJlY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NpcHJlY10gIzY4OiBTdGFydC9zdG9w IHRpbWUgZm9yIFJlY29yZGluZyBTZXNzaW9uDQo+IA0KPiAjNjg6IFN0YXJ0L3N0b3AgdGltZSBm b3IgUmVjb3JkaW5nIFNlc3Npb24NCj4gDQo+IENoYW5nZXMgKGJ5IHBhcnRyQOKApik6DQo+IA0K PiAgICogc3RhdHVzOiAgbmV3ID0+IGNsb3NlZA0KPiAgICogcmVzb2x1dGlvbjogID0+IGZpeGVk DQo+IA0KPiANCj4gLS0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgUmVwb3J0ZXI6ICBqb2hu LmVsd2VsbEDigKYgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgIE93bmVyOiAgcm1vaGFu ckDigKYNCj4gICAgICBUeXBlOiAgZGVmZWN0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICBTdGF0dXM6ICBjbG9zZWQNCj4gIFByaW9yaXR5OiAgbWlub3IgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICBNaWxlc3RvbmU6DQo+IENvbXBvbmVudDogIE1ldGFkYXRh IE1vZGVsICAgICAgICAgICAgICAgICAgICAgIHwgICAgICBWZXJzaW9uOg0KPiAgU2V2ZXJpdHk6 ICBBY3RpdmUgV0cgRG9jdW1lbnQgICAgICAgICAgICAgICAgICB8ICAgUmVzb2x1dGlvbjogIGZp eGVkDQo+ICBLZXl3b3JkczogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gVGlja2V0IFVSTDogPGh0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL3dnL3NpcHJlYy90cmFjL3RpY2tldC82OCNjb21tZW50OjE+DQo+IHNpcHJl YyA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3NpcHJlYy8+DQo+IA0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzaXByZWMgbWFpbGluZyBsaXN0DQo+ IHNpcHJlY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NpcHJlYw0K From pravindran@sonusnet.com Tue Aug 23 18:19:53 2011 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 C09EC21F8BE8 for ; Tue, 23 Aug 2011 18:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 vTgHAlDp3xe0 for ; Tue, 23 Aug 2011 18:19:53 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2958221F8BE4 for ; Tue, 23 Aug 2011 18:19:53 -0700 (PDT) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p7O1LSWn021818; Tue, 23 Aug 2011 21:21:28 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Aug 2011 21:20:29 -0400 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, 24 Aug 2011 06:50:26 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51064240@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] #68: Start/stop time for Recording Session Thread-Index: Acxg98LIkhXHYrFoSL61/QGes7mOXAA4QefAAAhS7gA= References: <075.db8ff04b7cbf099d401d476dc3008b5f@trac.tools.ietf.org><084.53cdc48fc0a5a2dadeb3fd8d93617fb2@trac.tools.ietf.org> From: "Ravindran Parthasarathi" To: "Charles Eckel (eckelcu)" , "siprec issue tracker" , "Ram Mohan R (rmohanr)" , "Parthasarathi R (partr)" X-OriginalArrivalTime: 24 Aug 2011 01:20:29.0691 (UTC) FILETIME=[03005CB0:01CC61FC] Cc: siprec@ietf.org Subject: Re: [siprec] #68: Start/stop time for Recording Session X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 01:19:53 -0000 SGkgQ2hhcmxlcywNCg0KU29ycnksIEknbGwgYWRkIHRoZSByZWFzb24gZm9yIHRoZSBmb3J0aGNv bWluZyB0aWNrZXQgYmVmb3JlIGNsb3NpbmcuDQoNClRoZSB0aWNrZXQgd2FzIG9wZW5lZCBhZnRl ciBJRVRGLTgwIHdoZW4gUmVjb3JkaW5nIHNlc3Npb24gaXMgY29uc2lkZXJlZCBhcyBwYXJ0IG9m IG1ldGFkYXRhIFhNTCBhbmQgbGF0ZXIsIGl0IHdhcyBkZWNpZGVkIHRvIGJlIHBhcnQgb2YgUlMg ZGlhbG9nIChTSVAgbWVzc2FnZSkuIFNvLCB0aGUgdGlja2V0IHJlcXVpcmVtZW50IG9mIFJlY29y ZGluZyBzZXNzaW9uIHN0YXJ0L3N0b3AgdGltZSBpcyBubyBsb25nZXIgdmFsaWQuDQoNClRoYW5r cw0KUGFydGhhDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IHNpcHJlYy1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86c2lwcmVjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs Zg0KPk9mIENoYXJsZXMgRWNrZWwgKGVja2VsY3UpDQo+U2VudDogV2VkbmVzZGF5LCBBdWd1c3Qg MjQsIDIwMTEgMjozOSBBTQ0KPlRvOiBzaXByZWMgaXNzdWUgdHJhY2tlcjsgUmFtIE1vaGFuIFIg KHJtb2hhbnIpOyBQYXJ0aGFzYXJhdGhpIFIgKHBhcnRyKQ0KPkNjOiBzaXByZWNAaWV0Zi5vcmcN Cj5TdWJqZWN0OiBSZTogW3NpcHJlY10gIzY4OiBTdGFydC9zdG9wIHRpbWUgZm9yIFJlY29yZGlu ZyBTZXNzaW9uDQo+DQo+SSBoYWQgaG9wZWQgdGhlIHJlc29sdXRpb24gY291bGQgc3RhdGUgd2hh dCB3YXMgZGVjaWRlZCBhbmQgd2h5IHNvIHRoYXQNCj53ZSBkbyBub3QgY2lyY2xlIGJhY2sgb24g dGhpcyBhZ2Fpbi4gSSBhbHJlYWR5IGZvcmdvdCB3aGF0IHdlIGRlY2lkZWQgOikNCj4NCj5DaGVl cnMsDQo+Q2hhcmxlcw0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206 IHNpcHJlYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2lwcmVjLWJvdW5jZXNAaWV0Zi5vcmdd IE9uDQo+QmVoYWxmIE9mIHNpcHJlYyBpc3N1ZSB0cmFja2VyDQo+PiBTZW50OiBNb25kYXksIEF1 Z3VzdCAyMiwgMjAxMSAxMToxNyBBTQ0KPj4gVG86IFJhbSBNb2hhbiBSIChybW9oYW5yKTsgUGFy dGhhc2FyYXRoaSBSIChwYXJ0cikNCj4+IENjOiBzaXByZWNAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6 IFJlOiBbc2lwcmVjXSAjNjg6IFN0YXJ0L3N0b3AgdGltZSBmb3IgUmVjb3JkaW5nIFNlc3Npb24N Cj4+DQo+PiAjNjg6IFN0YXJ0L3N0b3AgdGltZSBmb3IgUmVjb3JkaW5nIFNlc3Npb24NCj4+DQo+ PiBDaGFuZ2VzIChieSBwYXJ0ckDigKYpOg0KPj4NCj4+ICAgKiBzdGF0dXM6ICBuZXcgPT4gY2xv c2VkDQo+PiAgICogcmVzb2x1dGlvbjogID0+IGZpeGVkDQo+Pg0KPj4NCj4+IC0tDQo+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+LS0tLS0tDQo+PiAgUmVwb3J0ZXI6ICBqb2huLmVsd2VsbEDigKYgICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgIE93bmVyOg0KPnJtb2hhbnJA4oCmDQo+PiAgICAgIFR5 cGU6ICBkZWZlY3QgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIFN0YXR1czoN Cj5jbG9zZWQNCj4+ICBQcmlvcml0eTogIG1pbm9yICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgTWlsZXN0b25lOg0KPj4gQ29tcG9uZW50OiAgTWV0YWRhdGEgTW9kZWwgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgIFZlcnNpb246DQo+PiAgU2V2ZXJpdHk6ICBBY3RpdmUgV0cg RG9jdW1lbnQgICAgICAgICAgICAgICAgICB8ICAgUmVzb2x1dGlvbjogIGZpeGVkDQo+PiAgS2V5 d29yZHM6ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+PiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+LS0tLS0tDQo+Pg0KPj4gVGlja2V0IFVSTDoNCj48aHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvd2cvc2lwcmVjL3RyYWMvdGlja2V0LzY4I2NvbW1lbnQ6MT4NCj4+IHNpcHJlYyA8 aHR0cDovL3Rvb2xzLmlldGYub3JnL3NpcHJlYy8+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHNpcHJlYyBtYWlsaW5nIGxpc3QNCj4+ IHNpcHJlY0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zaXByZWMNCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPnNpcHJlYyBtYWlsaW5nIGxpc3QNCj5zaXByZWNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcHJlYw0K From john.elwell@siemens-enterprise.com Wed Aug 24 00:47:41 2011 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 9368F21F8A62 for ; Wed, 24 Aug 2011 00:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.189 X-Spam-Level: X-Spam-Status: No, score=-103.189 tagged_above=-999 required=5 tests=[AWL=-0.590, 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 59n-530ZK3et for ; Wed, 24 Aug 2011 00:47:40 -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 5758621F89B8 for ; Wed, 24 Aug 2011 00:47:34 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id E2AED1EB8442; Wed, 24 Aug 2011 09:48:40 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 24 Aug 2011 09:48:41 +0200 From: "Elwell, John" To: "Charles Eckel (eckelcu)" , Paul Kyzivat , "siprec@ietf.org" Date: Wed, 24 Aug 2011 09:48:39 +0200 Thread-Topic: [siprec] SRS-initiated INVITE Thread-Index: AcxhpLMuIJ9FkXicQtaeTNyHx7+jIwAKSxLAAAJz2YAAFnh0QA== Message-ID: References: <4E53BF55.3010309@alum.mit.edu> 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] SRS-initiated INVITE 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, 24 Aug 2011 07:47:41 -0000 Charles,,=20 > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]=20 > Sent: 23 August 2011 22:06 > To: Elwell, John; Paul Kyzivat; siprec@ietf.org > Subject: RE: [siprec] SRS-initiated INVITE >=20 > Hi John, >=20 > I was envisioning a use case in which the INVITE from the SRS=20 > to the SRC > contains a Request-URI for a call that is to be joined for the purpose > of recording (e.g. a conference call). The SRS may include=20 > SDP as well. [JRE] So this would be a different use case, for recording only a specific = call. Did you envisage using the Join or Target-Dialog header field to iden= tify the CS dialog? > The SRC could initiate the CS INVITE in this case.=20 [JRE] Not sure I understand this. I had assumed, from what you said at the = start, that the purpose would be to record a CS already in progress, so the= initial CS INVITE would be history. I can't imagine why the SRS would want= the SRC to establish a CS for the purpose of recording. John (as individual) > I'd like to hear what others think about making your proposal more > generic to accommodate that as well. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > > Sent: Tuesday, August 23, 2011 12:51 PM > > To: Paul Kyzivat; siprec@ietf.org > > Subject: Re: [siprec] SRS-initiated INVITE > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > > Sent: 23 August 2011 15:55 > > > To: siprec@ietf.org > > > Subject: Re: [siprec] SRS-initiated INVITE > > > > > > IIUC, the essential feature of this flow is that the R-URI > > > from SRS to > > > SRC in some way encodes the criteria for what calls the SRC > > > should record. > > > > > > I guess you are assuming that the manner of that encoding is > > > unstandardized, and hence requires a side agreement between > > > the SRC and > > > SRS. Or else it requires that the SRS be configurable to > > > establish an RS > > > to an arbitrary URI, and that the administrator is aware of > > > the specific > > > URI encoding required by the SRC to achieve the intended effect. > > > > > > While that is a bit of a stretch, I don't have any particular > problem > > > with including such an example. But this doesn't ensure=20 > that any SRC > > > actually has this capability. > > [JRE] Quite so. But if the SRC has a URI that can be used=20 > and the SRS > is configured with that URI, it > > should work. > >=20 > > John > >=20 > >=20 > > > > > > Thanks, > > > Paul > > > > > > On 8/23/11 7:03 AM, Elwell, John wrote: > > > > (as individual) > > > > > > > > During the IETF 81 session, Andy and I agreed to propose > > > some text for the protocol document to cover the case of > > > SRS-initiated INVITE in more detail. This is our proposal: > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > > > The following is a sample call flow that shows the SRS > > > establishing a recording session towards the SRC. The most > > > likely application of this is for persistent recording, where > > > the SRS does not need to have prior knowledge of particular > > > CSs that need to be recorded but simply requires to record > > > all CSs with certain characteristics (e.g., involving a > > > particular user). Also it is more likely to arise when the > > > SRC is located at a B2BUA, rather than at a UA, and therefore > > > the SRS does not need to identify a particular UA as the > > > target of the INVITE request. > > > > > > > > > > > > UA A SRC UA B > > > SRS > > > > | | (1) RS INVITE without SDP > | > > > > | > |<---------------------------------------------| > > > > | | (2) OK with SDP > | > > > > | > |--------------------------------------------->| > > > > | | (3) ACK with SDP > | > > > > | > |<---------------------------------------------| > > > > |(4)CS INVITE | | > | > > > > |------------->| | > | > > > > | |(5)CS INVITE | > | > > > > | |---------------------->| > | > > > > | | (6)OK | > | > > > > | |<----------------------| > | > > > > | (7)OK | | > | > > > > |<-------------| | > | > > > > | |(8)RS UPDATE with SDP and metadata > | > > > > | > |--------------------------------------------->| > > > > | | (9)OK with SDP > | > > > > | > |<---------------------------------------------| > > > > |(10)CS RTP | | > | > > > > |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > | > > > > |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|<=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| > | > > > > | |(11)RS RTP | > | > > > > | > |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > > > | > |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > > > |(12)CS BYE | | > | > > > > |------------->| | > | > > > > | |(13)CS BYE | > | > > > > | |---------------------->| > | > > > > | | (14) CS OK | > | > > > > | |<----------------------| > | > > > > | (15)OK | | > | > > > > |<-------------| | > | > > > > | |(16)UPDATE with SDP and metadata > > > | | > > > > | > |--------------------------------------------->| > > > > | | (17)OK with SDP > | > > > > | > |<---------------------------------------------| > > > > | | | > | > > > > > > > > Figure 2: Persistent Recording Call Flow, RS > > > Established by SRS > > > > > > > > The initial INVITE request for establishing the RS (1) has > > > a Request-URI that identifies the SRC and instructs the SRC > > > what to record (e.g., all CSs involving a particular user). > > > The SDP offer from the SRC (2) might have no media or might > > > establish inactive media in anticipation of future requirements. > > > > > > > > The first UPDATE request (8) occurs on establishment of a > > > recordable CS. It includes metadata describing the CS and, if > > > necessary, includes a new SDP offer to establish or modify > > > media streams needed for recording that CS. > > > > > > > > The second UPDATE request (16) occurs on termination of a > > > recordable CS. It includes metadata indicating termination of > > > the CS and might include a new SDP offer changing media > > > streams that are no longer wanted to disabled or inactive. > > > Because this is persistent recording, the RS would typically > > > remain in place awaiting other recordable CSs. > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > Other places in the document will also need some changes, > > > but I would like first to see if we can get agreement on the > > > general principle and on inclusion of this scenario in section 4. > > > > > > > > John > > > > > > > > > > > > John Elwell > > > > Tel: +44 1908 817801 (office and mobile) > > > > Email: john.elwell@siemens-enterprise.com > > > > http://www.siemens-enterprise.com/uk/ > > > > > > > > Siemens Enterprise Communications Limited. > > > > Registered office: Brickhill Street, Willen Lake, Milton > > > Keynes, MK15 0DJ. > > > > Registered No: 5903714, England. > > > > > > > > Siemens Enterprise Communications Limited is a Trademark > > > Licensee of Siemens AG. > > > > > > > > > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > = From john.elwell@siemens-enterprise.com Wed Aug 24 00:51:37 2011 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 3C29E21F8451 for ; Wed, 24 Aug 2011 00:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.185 X-Spam-Level: X-Spam-Status: No, score=-103.185 tagged_above=-999 required=5 tests=[AWL=-0.586, 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 T0Vy3JmkG5mZ for ; Wed, 24 Aug 2011 00:51:36 -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 66F7721F8B15 for ; Wed, 24 Aug 2011 00:51:34 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 0C1AC1EB8447; Wed, 24 Aug 2011 09:52:44 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 24 Aug 2011 09:52:44 +0200 From: "Elwell, John" To: "Charles Eckel (eckelcu)" , Paul Kyzivat Date: Wed, 24 Aug 2011 09:52:42 +0200 Thread-Topic: [siprec] Do we need a stream element? Thread-Index: Acxhn/lfy6dNyIaSQRa2IBM89xEG3wACzGNgAAovh2AAF6dbcA== Message-ID: References: <4E3BFC29.6050001@alum.mit.edu><4E402C2F.1080103@alum.mit.edu><07465C1D981ABC41A344374066AE1A2C38B0304DA2@TLVMBX01.nice.com> <2E239D6FCD033C4BAF15F386A979BF510640D1@sonusinmail02.sonusnet.com> <4E525EB8.9050405@alum.mit.edu> <2E239D6FCD033C4BAF15F386A979BF5106416E@sonusinmail02.sonusnet.com> <4E526896.60505@alum.mit.edu> <4E527645.5060807@alum.mit.edu> <4E53B75F.9090505@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Do we need a stream element? 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, 24 Aug 2011 07:51:37 -0000 Charles,=20 > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]=20 > Sent: 23 August 2011 21:49 > To: Elwell, John; Paul Kyzivat > Cc: Ravindran Parthasarathi; Leon Portman; siprec@ietf.org > Subject: RE: [siprec] Do we need a stream element? >=20 > Hi John, >=20 > From all the examples, I do not yet see much value. The only case in > which I have seen some value is the case of an SRS that is=20 > handling many > recordings being able to detect that it is receiving multiple=20 > copies of > the same stream and optimizing to record only a single instance of it > (e.g. the multicast MoH case). For this specific case, it may=20 > be better > to add a mechanism to not record it at all. My thought is SRC > implementations may be smart enough to not include such streams in the > RS. But that is outside the scope of SIPREC. And in general, I am not > sure how likely it is that the SRCs will recognize this=20 > stream as being > the same, and use the same ID for it. > Using the same MS to represent the media from a participant before and > after a transfer does not seem necessary to me. As long as the media > before and after the transfer is associated with the same participant, > that seems sufficient to me. [JRE] Thanks for expressing more clearly my own thoughts. > My main hesitation with saying it is not necessary is that several > people seem to be making arguments for why it is necessary.=20 > My question > to them is, are you pointing out hypothetical use cases that you agree > are edge cases that can be ignored for now, or are these use cases > really of great interest to you. [JRE] Yes, this is what we really need to know. John (as individual) >=20 > Cheers, > Charles=20 >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Tuesday, August 23, 2011 8:50 AM > > To: Paul Kyzivat > > Cc: Ravindran Parthasarathi; Charles Eckel (eckelcu); Leon Portman; > siprec@ietf.org > > Subject: RE: [siprec] Do we need a stream element? > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > > Sent: 23 August 2011 15:21 > > > To: Elwell, John > > > Cc: Ravindran Parthasarathi; Charles Eckel (eckelcu); Leon > > > Portman; siprec@ietf.org > > > Subject: Re: [siprec] Do we need a stream element? > > > > > > On 8/23/11 6:44 AM, Elwell, John wrote: > > > [snip] > > > >> John, > > > >> > > > >> I share your discomfort - I don't think the definition is > > > right yet. > > > >> But I do think there is a concept there needing a definition. > > > >> > > > >> Some *examples* of this: > > > >> > > > >> - my "side" of the audio part of a conversation with you, > > > >> contained within a CS between you and me. > > > >> > > > >> - my "side" of the audio part of a conversation with a call > center > > > >> agent, contained within a CS between me and him, but also > going > > > >> to the call center supervisor who is listening in. > > > >> > > > >> - a mix of the audio part of a conversation between me and you, > > > >> from my perspective, including the audio I sent to you and > the > > > >> audio I received from you. > > > >> > > > >> - a MoH audio stream generated and sent by your phone when you > put > > > >> me on hold. > > > >> > > > >> - a MoH audio stream sent by an MoH server to whom I have been > > > >> transferred while on hold. A unique stream=20 > generated for me. > > > >> > > > >> - a MoH multicast audio stream that was offered to me by you > > > >> when you put me on hold. That same stream has been > > > shared by all > > > >> those put on hold by the PBX you use. > > > >> > > > >> - a mixed audio stream for a conference. It contains a=20 > mix of the > > > >> loudest two participants at any one time. > > > >> > > > >> In each case, the media stream exists over a period of time. > > > >> The contents of the stream can be forwarded to the SRS using > > > >> one of the > > > >> RTP streams in an RS. And portions of that MS might be > > > >> forwarded using > > > >> different RTP streams and/or RSs. > > > >> > > > >> Without yet nailing down the definition, do you agree that > > > there is a > > > >> well defined concept (class) here? > > > > [JRE] Yes, each of the examples you give can be an MS. And > > > I guess it is possible you could terminate an RS and start a > > > new RS to resume recording of the same MS, so there might not > > > be a 1:1 relationship between MS and RS. > > > > > > Yes, that is my thinking. > > > > > > > None of these examples show why a MS can have a lifetime > > > outside a CS - they all sound to me like they are implicitly > > > within the context of a CS. So it doesn't answer my question > > > about when a stream in the context of one CS is considered to > > > be the same as a stream in the context of another CS, and > > > hence the same MS object. > > > > > > The multicast MoH stream was intended as an example of this case. > > > It may indeed go on continuously regardless of whether=20 > there are any > > > receivers. > > [JRE] OK, I understand now, but is the stream really of=20 > interest while > there are no receivers, and > > when a receiver does appear again and it needs to be recorded again, > what benefit arises from saying > > it is the same stream, as opposed to some new stream? > >=20 > > > > > > > Or putting it another way, if there is no CS in existence > > > at a given point in time, I would assume there is no MS in > > > existence. So when the last CSs terminates, do its associated > > > MSs die, or can they exist in a sort of hibernation and be > > > revived when the next CS starts? Or in this situation, does > > > the new CS have to have new MSs? > > > > > > Based on my prior comment, I think the MS can indeed exist > > > without any > > > CS referencing it. Of course in that case its most likely > > > that it will > > > not be recorded. > > > > > > Treating it this way means that in a large deployment=20 > there might be > > > hundreds of calls on hold, but the SRS could recognize that > > > they are all > > > receiving the same stream and so record it only once. > > [JRE] This requires the SRC to recognize that two or more=20 > participants > in different CSs are really > > receiving the same stream. I don't know how often that will occur in > practice. But then consider what > > happens at the SRS - does it record the stream only once,=20 > and as part > of which CS recording? It would > > need to avoid the problem that, but deleting one CS=20 > recording, it also > deletes a stream that other CS > > recordings depend on. On the other hand, if the stream is recorded > independently of any CS recording, > > then what would trigger its deletion when all CS recordings that use > it have been deleted (garbage > > collection)? > >=20 > > I can see that having a separate identifier for a stream could have > benefits, but they seem like > > corner cases to me. It is a question of whether the WG=20 > feels the added > overhead is justified. > >=20 > > John (as individual) > >=20 > >=20 > > John Elwell > > Tel: +44 1908 817801 (office and mobile) > > Email: john.elwell@siemens-enterprise.com > > http://www.siemens-enterprise.com/uk/ > >=20 > > Siemens Enterprise Communications Limited. > > Registered office: Brickhill Street, Willen Lake, Milton=20 > Keynes, MK15 > 0DJ. > > Registered No: 5903714, England. > >=20 > > Siemens Enterprise Communications Limited is a Trademark Licensee of > Siemens AG. > >=20 > > > > > > (And yes, I do know of systems that use multicast for MoH.) > > > > > > > > > Thanks, > > > Paul > > > > = From pkyzivat@alum.mit.edu Wed Aug 24 12:21:31 2011 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 0C82F21F8C60 for ; Wed, 24 Aug 2011 12:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 uUQwVFs7ijTA for ; Wed, 24 Aug 2011 12:21:29 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id BBA6021F8715 for ; Wed, 24 Aug 2011 12:21:28 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta10.westchester.pa.mail.comcast.net with comcast id QJt01h0031HzFnQ5AKNg7p; Wed, 24 Aug 2011 19:22:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta14.westchester.pa.mail.comcast.net with comcast id QKNf1h00E0tdiYw3aKNf5H; Wed, 24 Aug 2011 19:22:40 +0000 Message-ID: <4E554F7D.8010802@alum.mit.edu> Date: Wed, 24 Aug 2011 15:22:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Elwell, John" References: <4E402C2F.1080103@alum.mit.edu><07465C1D981ABC41A344374066AE1A2C38B0304DA2@TLVMBX01.nice.com> <2E239D6FCD033C4BAF15F386A979BF510640D1@sonusinmail02.sonusnet.com> <4E525EB8.9050405@alum.mit.edu> <2E239D6FCD033C4BAF15F386A979BF5106416E@sonusinmail02.sonusnet.com> <4E526896.60505@alum.mit.edu> <4E527645.5060807@alum.mit.edu> <4E53B75F.9090505@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Do we need a stream element? 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, 24 Aug 2011 19:21:31 -0000 On 8/24/11 3:52 AM, Elwell, John wrote: > Charles, > >> -----Original Message----- >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >> Sent: 23 August 2011 21:49 >> To: Elwell, John; Paul Kyzivat >> Cc: Ravindran Parthasarathi; Leon Portman; siprec@ietf.org >> Subject: RE: [siprec] Do we need a stream element? >> >> Hi John, >> >> From all the examples, I do not yet see much value. The only case in >> which I have seen some value is the case of an SRS that is >> handling many >> recordings being able to detect that it is receiving multiple >> copies of >> the same stream and optimizing to record only a single instance of it >> (e.g. the multicast MoH case). For this specific case, it may >> be better >> to add a mechanism to not record it at all. My thought is SRC >> implementations may be smart enough to not include such streams in the >> RS. But that is outside the scope of SIPREC. And in general, I am not >> sure how likely it is that the SRCs will recognize this >> stream as being >> the same, and use the same ID for it. >> Using the same MS to represent the media from a participant before and >> after a transfer does not seem necessary to me. As long as the media >> before and after the transfer is associated with the same participant, >> that seems sufficient to me. > [JRE] Thanks for expressing more clearly my own thoughts. > >> My main hesitation with saying it is not necessary is that several >> people seem to be making arguments for why it is necessary. >> My question >> to them is, are you pointing out hypothetical use cases that you agree >> are edge cases that can be ignored for now, or are these use cases >> really of great interest to you. > [JRE] Yes, this is what we really need to know. I freely admit that for me these are hypothetical cases, in that I don't have an actual implementation that I am speaking for. But IMO, while use cases are very important, corner cases are also important. It is the corner cases that define the boundaries of what you are defining. (And that is true whether you decide the corner is "in" or "out".) In this case, I think we are deciding whether to make a special case of MS, as contrasted to most of the other elements. The corner cases are handled it we treat it like other things, while the corner cases are excluded if we special case it. The argument for the special case is efficiency. But its not clear to me how much efficiency it affords - I'm inclined to think it isn't much. So IMO this just adds an added argument in favor of *not* special casing MS, which would be my normal inclination in any case unless there were compelling arguments for why the optimization was needed. Thanks, Paul > John (as individual) > > >> >> Cheers, >> Charles >> >>> -----Original Message----- >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>> Sent: Tuesday, August 23, 2011 8:50 AM >>> To: Paul Kyzivat >>> Cc: Ravindran Parthasarathi; Charles Eckel (eckelcu); Leon Portman; >> siprec@ietf.org >>> Subject: RE: [siprec] Do we need a stream element? >>> >>> >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: 23 August 2011 15:21 >>>> To: Elwell, John >>>> Cc: Ravindran Parthasarathi; Charles Eckel (eckelcu); Leon >>>> Portman; siprec@ietf.org >>>> Subject: Re: [siprec] Do we need a stream element? >>>> >>>> On 8/23/11 6:44 AM, Elwell, John wrote: >>>> [snip] >>>>>> John, >>>>>> >>>>>> I share your discomfort - I don't think the definition is >>>> right yet. >>>>>> But I do think there is a concept there needing a definition. >>>>>> >>>>>> Some *examples* of this: >>>>>> >>>>>> - my "side" of the audio part of a conversation with you, >>>>>> contained within a CS between you and me. >>>>>> >>>>>> - my "side" of the audio part of a conversation with a call >> center >>>>>> agent, contained within a CS between me and him, but also >> going >>>>>> to the call center supervisor who is listening in. >>>>>> >>>>>> - a mix of the audio part of a conversation between me and you, >>>>>> from my perspective, including the audio I sent to you and >> the >>>>>> audio I received from you. >>>>>> >>>>>> - a MoH audio stream generated and sent by your phone when you >> put >>>>>> me on hold. >>>>>> >>>>>> - a MoH audio stream sent by an MoH server to whom I have been >>>>>> transferred while on hold. A unique stream >> generated for me. >>>>>> >>>>>> - a MoH multicast audio stream that was offered to me by you >>>>>> when you put me on hold. That same stream has been >>>> shared by all >>>>>> those put on hold by the PBX you use. >>>>>> >>>>>> - a mixed audio stream for a conference. It contains a >> mix of the >>>>>> loudest two participants at any one time. >>>>>> >>>>>> In each case, the media stream exists over a period of time. >>>>>> The contents of the stream can be forwarded to the SRS using >>>>>> one of the >>>>>> RTP streams in an RS. And portions of that MS might be >>>>>> forwarded using >>>>>> different RTP streams and/or RSs. >>>>>> >>>>>> Without yet nailing down the definition, do you agree that >>>> there is a >>>>>> well defined concept (class) here? >>>>> [JRE] Yes, each of the examples you give can be an MS. And >>>> I guess it is possible you could terminate an RS and start a >>>> new RS to resume recording of the same MS, so there might not >>>> be a 1:1 relationship between MS and RS. >>>> >>>> Yes, that is my thinking. >>>> >>>>> None of these examples show why a MS can have a lifetime >>>> outside a CS - they all sound to me like they are implicitly >>>> within the context of a CS. So it doesn't answer my question >>>> about when a stream in the context of one CS is considered to >>>> be the same as a stream in the context of another CS, and >>>> hence the same MS object. >>>> >>>> The multicast MoH stream was intended as an example of this case. >>>> It may indeed go on continuously regardless of whether >> there are any >>>> receivers. >>> [JRE] OK, I understand now, but is the stream really of >> interest while >> there are no receivers, and >>> when a receiver does appear again and it needs to be recorded again, >> what benefit arises from saying >>> it is the same stream, as opposed to some new stream? >>> >>>> >>>>> Or putting it another way, if there is no CS in existence >>>> at a given point in time, I would assume there is no MS in >>>> existence. So when the last CSs terminates, do its associated >>>> MSs die, or can they exist in a sort of hibernation and be >>>> revived when the next CS starts? Or in this situation, does >>>> the new CS have to have new MSs? >>>> >>>> Based on my prior comment, I think the MS can indeed exist >>>> without any >>>> CS referencing it. Of course in that case its most likely >>>> that it will >>>> not be recorded. >>>> >>>> Treating it this way means that in a large deployment >> there might be >>>> hundreds of calls on hold, but the SRS could recognize that >>>> they are all >>>> receiving the same stream and so record it only once. >>> [JRE] This requires the SRC to recognize that two or more >> participants >> in different CSs are really >>> receiving the same stream. I don't know how often that will occur in >> practice. But then consider what >>> happens at the SRS - does it record the stream only once, >> and as part >> of which CS recording? It would >>> need to avoid the problem that, but deleting one CS >> recording, it also >> deletes a stream that other CS >>> recordings depend on. On the other hand, if the stream is recorded >> independently of any CS recording, >>> then what would trigger its deletion when all CS recordings that use >> it have been deleted (garbage >>> collection)? >>> >>> I can see that having a separate identifier for a stream could have >> benefits, but they seem like >>> corner cases to me. It is a question of whether the WG >> feels the added >> overhead is justified. >>> >>> John (as individual) >>> >>> >>> John Elwell >>> Tel: +44 1908 817801 (office and mobile) >>> Email: john.elwell@siemens-enterprise.com >>> http://www.siemens-enterprise.com/uk/ >>> >>> Siemens Enterprise Communications Limited. >>> Registered office: Brickhill Street, Willen Lake, Milton >> Keynes, MK15 >> 0DJ. >>> Registered No: 5903714, England. >>> >>> Siemens Enterprise Communications Limited is a Trademark Licensee of >> Siemens AG. >>> >>>> >>>> (And yes, I do know of systems that use multicast for MoH.) >>>> >>>> >>>> Thanks, >>>> Paul >>>> >> From eckelcu@cisco.com Wed Aug 24 13:28:14 2011 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 1468521F8CCA for ; Wed, 24 Aug 2011 13:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.772 X-Spam-Level: X-Spam-Status: No, score=-2.772 tagged_above=-999 required=5 tests=[AWL=-0.173, 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 xxt8IGxTw0fe for ; Wed, 24 Aug 2011 13:28:13 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A9F7321F8CCC for ; Wed, 24 Aug 2011 13:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=10381; q=dns/txt; s=iport; t=1314217764; x=1315427364; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=t9FJyA9SZI3OzLEKXWmDCExLy88T35Zu77Ci/TREtII=; b=OxOr8o5L9Q9KzfFgnDRgcP0ohx7EkB7lgAz1ls0HLe2q+z7SAO5ZEz+M SRPO0KVXRmhXhwBTWB2izP7jzf4RRoYZQnTHMYaizFEK5GTL25k6st6mX OnY1qnxgEYdZ8LgemRndaLUIttSRX/HdB1uekZUG0AP1olb51hm6V7UmL 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroAAPldVU6rRDoG/2dsb2JhbAA4Cg6YGY9Zd4FAAQEBAQIBAQEBDwEUCQouBhcEAgEIEQQBAQEKBhcBBgEmHwkIAQEEARIIGodPBJscAZ8YgyeCQ18Eh2GQTostWA X-IronPort-AV: E=Sophos;i="4.68,277,1312156800"; d="scan'208";a="16194503" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-4.cisco.com with ESMTP; 24 Aug 2011 20:29:23 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7OKTKIU020454; Wed, 24 Aug 2011 20:29:23 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Aug 2011 13:29:20 -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, 24 Aug 2011 13:29:19 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] SRS-initiated INVITE Thread-Index: AcxhpLMuIJ9FkXicQtaeTNyHx7+jIwAKSxLAAAJz2YAAFnh0QAAaXGZg References: <4E53BF55.3010309@alum.mit.edu> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , "Paul Kyzivat" , X-OriginalArrivalTime: 24 Aug 2011 20:29:20.0099 (UTC) FILETIME=[80B9EB30:01CC629C] Subject: Re: [siprec] SRS-initiated INVITE 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, 24 Aug 2011 20:28:14 -0000 Please see inline. > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Wednesday, August 24, 2011 12:49 AM > To: Charles Eckel (eckelcu); Paul Kyzivat; siprec@ietf.org > Subject: RE: [siprec] SRS-initiated INVITE >=20 > Charles,, >=20 > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > Sent: 23 August 2011 22:06 > > To: Elwell, John; Paul Kyzivat; siprec@ietf.org > > Subject: RE: [siprec] SRS-initiated INVITE > > > > Hi John, > > > > I was envisioning a use case in which the INVITE from the SRS > > to the SRC > > contains a Request-URI for a call that is to be joined for the purpose > > of recording (e.g. a conference call). The SRS may include > > SDP as well. > [JRE] So this would be a different use case, for recording only a specific call. Did you envisage > using the Join or Target-Dialog header field to identify the CS dialog? >=20 > > The SRC could initiate the CS INVITE in this case. I do not think either of those is really appropriate for this. > [JRE] Not sure I understand this. I had assumed, from what you said at the start, that the purpose > would be to record a CS already in progress, so the initial CS INVITE would be history. I can't > imagine why the SRS would want the SRC to establish a CS for the purpose of recording. >=20 > John (as individual) Take the case of a conference call is that is not being recorded. At some point in time, someone decides they want to start recording the conference. This could be done by a SIP UA that is participating in the conference, or by the focus of the conference, acting as or interacting with the SRC. This is already covered by our use cases. But it could also be accomplished using some mechanism outside the scope of the SIPREC that asks the SRS to record the conference. While the trigger is outside the scope of SIPREC, the way the SRS initiates the RS is what I think could be considered in scope for SIPREC. Cheers, Charles =20 >=20 > > I'd like to hear what others think about making your proposal more > > generic to accommodate that as well. > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > > > Sent: Tuesday, August 23, 2011 12:51 PM > > > To: Paul Kyzivat; siprec@ietf.org > > > Subject: Re: [siprec] SRS-initiated INVITE > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > > > Sent: 23 August 2011 15:55 > > > > To: siprec@ietf.org > > > > Subject: Re: [siprec] SRS-initiated INVITE > > > > > > > > IIUC, the essential feature of this flow is that the R-URI > > > > from SRS to > > > > SRC in some way encodes the criteria for what calls the SRC > > > > should record. > > > > > > > > I guess you are assuming that the manner of that encoding is > > > > unstandardized, and hence requires a side agreement between > > > > the SRC and > > > > SRS. Or else it requires that the SRS be configurable to > > > > establish an RS > > > > to an arbitrary URI, and that the administrator is aware of > > > > the specific > > > > URI encoding required by the SRC to achieve the intended effect. > > > > > > > > While that is a bit of a stretch, I don't have any particular > > problem > > > > with including such an example. But this doesn't ensure > > that any SRC > > > > actually has this capability. > > > [JRE] Quite so. But if the SRC has a URI that can be used > > and the SRS > > is configured with that URI, it > > > should work. > > > > > > John > > > > > > > > > > > > > > Thanks, > > > > Paul > > > > > > > > On 8/23/11 7:03 AM, Elwell, John wrote: > > > > > (as individual) > > > > > > > > > > During the IETF 81 session, Andy and I agreed to propose > > > > some text for the protocol document to cover the case of > > > > SRS-initiated INVITE in more detail. This is our proposal: > > > > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > The following is a sample call flow that shows the SRS > > > > establishing a recording session towards the SRC. The most > > > > likely application of this is for persistent recording, where > > > > the SRS does not need to have prior knowledge of particular > > > > CSs that need to be recorded but simply requires to record > > > > all CSs with certain characteristics (e.g., involving a > > > > particular user). Also it is more likely to arise when the > > > > SRC is located at a B2BUA, rather than at a UA, and therefore > > > > the SRS does not need to identify a particular UA as the > > > > target of the INVITE request. > > > > > > > > > > > > > > > UA A SRC UA B > > > > SRS > > > > > | | (1) RS INVITE without SDP > > | > > > > > | > > |<---------------------------------------------| > > > > > | | (2) OK with SDP > > | > > > > > | > > |--------------------------------------------->| > > > > > | | (3) ACK with SDP > > | > > > > > | > > |<---------------------------------------------| > > > > > |(4)CS INVITE | | > > | > > > > > |------------->| | > > | > > > > > | |(5)CS INVITE | > > | > > > > > | |---------------------->| > > | > > > > > | | (6)OK | > > | > > > > > | |<----------------------| > > | > > > > > | (7)OK | | > > | > > > > > |<-------------| | > > | > > > > > | |(8)RS UPDATE with SDP and metadata > > | > > > > > | > > |--------------------------------------------->| > > > > > | | (9)OK with SDP > > | > > > > > | > > |<---------------------------------------------| > > > > > |(10)CS RTP | | > > | > > > > > = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > | > > > > > = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| > > | > > > > > | |(11)RS RTP | > > | > > > > > | > > = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > > > > | > > = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > > > > |(12)CS BYE | | > > | > > > > > |------------->| | > > | > > > > > | |(13)CS BYE | > > | > > > > > | |---------------------->| > > | > > > > > | | (14) CS OK | > > | > > > > > | |<----------------------| > > | > > > > > | (15)OK | | > > | > > > > > |<-------------| | > > | > > > > > | |(16)UPDATE with SDP and metadata > > > > | | > > > > > | > > |--------------------------------------------->| > > > > > | | (17)OK with SDP > > | > > > > > | > > |<---------------------------------------------| > > > > > | | | > > | > > > > > > > > > > Figure 2: Persistent Recording Call Flow, RS > > > > Established by SRS > > > > > > > > > > The initial INVITE request for establishing the RS (1) has > > > > a Request-URI that identifies the SRC and instructs the SRC > > > > what to record (e.g., all CSs involving a particular user). > > > > The SDP offer from the SRC (2) might have no media or might > > > > establish inactive media in anticipation of future requirements. > > > > > > > > > > The first UPDATE request (8) occurs on establishment of a > > > > recordable CS. It includes metadata describing the CS and, if > > > > necessary, includes a new SDP offer to establish or modify > > > > media streams needed for recording that CS. > > > > > > > > > > The second UPDATE request (16) occurs on termination of a > > > > recordable CS. It includes metadata indicating termination of > > > > the CS and might include a new SDP offer changing media > > > > streams that are no longer wanted to disabled or inactive. > > > > Because this is persistent recording, the RS would typically > > > > remain in place awaiting other recordable CSs. > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > Other places in the document will also need some changes, > > > > but I would like first to see if we can get agreement on the > > > > general principle and on inclusion of this scenario in section 4. > > > > > > > > > > John > > > > > > > > > > > > > > > John Elwell > > > > > Tel: +44 1908 817801 (office and mobile) > > > > > Email: john.elwell@siemens-enterprise.com > > > > > http://www.siemens-enterprise.com/uk/ > > > > > > > > > > Siemens Enterprise Communications Limited. > > > > > Registered office: Brickhill Street, Willen Lake, Milton > > > > Keynes, MK15 0DJ. > > > > > Registered No: 5903714, England. > > > > > > > > > > Siemens Enterprise Communications Limited is a Trademark > > > > Licensee of Siemens AG. > > > > > > > > > > > > > > > _______________________________________________ > > > > > siprec mailing list > > > > > siprec@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > From john.elwell@siemens-enterprise.com Wed Aug 24 23:53:58 2011 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 5E7D321F8B05 for ; Wed, 24 Aug 2011 23:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.168 X-Spam-Level: X-Spam-Status: No, score=-103.168 tagged_above=-999 required=5 tests=[AWL=-0.569, 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 hh4d1K2SCvJF for ; Wed, 24 Aug 2011 23:53:57 -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 1786021F8B06 for ; Wed, 24 Aug 2011 23:53:57 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 73A2F23F05E4; Thu, 25 Aug 2011 08:55:06 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 25 Aug 2011 08:55:06 +0200 From: "Elwell, John" To: Paul Kyzivat Date: Thu, 25 Aug 2011 08:55:04 +0200 Thread-Topic: Consensus call - do we need a stream element? Thread-Index: AcxikzFCm1v0d3XPRkWipEktmk+/tAAXu/9g Message-ID: References: <4E402C2F.1080103@alum.mit.edu><07465C1D981ABC41A344374066AE1A2C38B0304DA2@TLVMBX01.nice.com> <2E239D6FCD033C4BAF15F386A979BF510640D1@sonusinmail02.sonusnet.com> <4E525EB8.9050405@alum.mit.edu> <2E239D6FCD033C4BAF15F386A979BF5106416E@sonusinmail02.sonusnet.com> <4E526896.60505@alum.mit.edu> <4E527645.5060807@alum.mit.edu> <4E53B75F.9090505@alum.mit.edu> <4E554F7D.8010802@alum.mit.edu> In-Reply-To: <4E554F7D.8010802@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: [siprec] Consensus call - do we need a stream element? 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, 25 Aug 2011 06:53:58 -0000 Paul gives a good summary below of the situation concerning the need for a = stream element. Based on Paul's arguments, I (as chair) would like to make = a consensus call to keep the media stream as a separate object in the model= and a separately identifiable element in XML, rather than realising the ob= ject solely through a reference to a labelled SDP media description. Even t= hough this introduces an inefficiency for the vast majority of situations, = there are potential corner cases where it would be useful. For other aspect= s of the model and its XML realisation we have erred on the side of flexibi= lity rather than fine-tuned efficiency, and handling media stream in this w= ay would be consistent with that principle. I don't think anyone has argued= why the potential efficiency savings in taking a different approach are co= mpelling. >From my personal point of view I would have preferred to eliminate the elem= ent, but I can live with keeping it. However, I know I was not alone in pre= ferring to eliminate it. So if anyone still feels we should eliminate the stream element in XML, ple= ase say so in the next week (by 2011-09-01). The editors are due to publish -04 by the end of the month, so I would sugg= est they retain the stream element in -04. If we don't achieve consensus to= keep it, we will have to address it in -05. John John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 > Sent: 24 August 2011 20:23 > To: Elwell, John > Cc: Charles Eckel (eckelcu); Ravindran Parthasarathi; Leon=20 > Portman; siprec@ietf.org > Subject: Re: [siprec] Do we need a stream element? >=20 > On 8/24/11 3:52 AM, Elwell, John wrote: > > Charles, > > > >> -----Original Message----- > >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >> Sent: 23 August 2011 21:49 > >> To: Elwell, John; Paul Kyzivat > >> Cc: Ravindran Parthasarathi; Leon Portman; siprec@ietf.org > >> Subject: RE: [siprec] Do we need a stream element? > >> > >> Hi John, > >> > >> From all the examples, I do not yet see much value. The=20 > only case in > >> which I have seen some value is the case of an SRS that is > >> handling many > >> recordings being able to detect that it is receiving multiple > >> copies of > >> the same stream and optimizing to record only a single=20 > instance of it > >> (e.g. the multicast MoH case). For this specific case, it may > >> be better > >> to add a mechanism to not record it at all. My thought is SRC > >> implementations may be smart enough to not include such=20 > streams in the > >> RS. But that is outside the scope of SIPREC. And in=20 > general, I am not > >> sure how likely it is that the SRCs will recognize this > >> stream as being > >> the same, and use the same ID for it. > >> Using the same MS to represent the media from a=20 > participant before and > >> after a transfer does not seem necessary to me. As long as=20 > the media > >> before and after the transfer is associated with the same=20 > participant, > >> that seems sufficient to me. > > [JRE] Thanks for expressing more clearly my own thoughts. > > > >> My main hesitation with saying it is not necessary is that several > >> people seem to be making arguments for why it is necessary. > >> My question > >> to them is, are you pointing out hypothetical use cases=20 > that you agree > >> are edge cases that can be ignored for now, or are these use cases > >> really of great interest to you. > > [JRE] Yes, this is what we really need to know. >=20 > I freely admit that for me these are hypothetical cases, > in that I don't have an actual implementation that I am speaking for. >=20 > But IMO, while use cases are very important, corner cases are also=20 > important. It is the corner cases that define the boundaries=20 > of what you=20 > are defining. (And that is true whether you decide the corner=20 > is "in" or=20 > "out".) >=20 > In this case, I think we are deciding whether to make a=20 > special case of=20 > MS, as contrasted to most of the other elements. The corner cases are=20 > handled it we treat it like other things, while the corner cases are=20 > excluded if we special case it. The argument for the special case is=20 > efficiency. But its not clear to me how much efficiency it=20 > affords - I'm=20 > inclined to think it isn't much. >=20 > So IMO this just adds an added argument in favor of *not*=20 > special casing=20 > MS, which would be my normal inclination in any case unless=20 > there were=20 > compelling arguments for why the optimization was needed. >=20 > Thanks, > Paul From Leon.Portman@nice.com Thu Aug 25 00:09:40 2011 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 7BDB621F8B3A for ; Thu, 25 Aug 2011 00:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 iAw-vkV4-rGU for ; Thu, 25 Aug 2011 00:09:38 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id D10AD21F8B2C for ; Thu, 25 Aug 2011 00:09:37 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Thu, 25 Aug 2011 10:10:47 +0300 From: Leon Portman To: "Elwell, John" , Paul Kyzivat Date: Thu, 25 Aug 2011 10:10:48 +0300 Thread-Topic: Consensus call - do we need a stream element? Thread-Index: AcxikzFCm1v0d3XPRkWipEktmk+/tAAXu/9gAAD7tlA= Message-ID: <07465C1D981ABC41A344374066AE1A2C38B041DA8E@TLVMBX01.nice.com> References: <4E402C2F.1080103@alum.mit.edu><07465C1D981ABC41A344374066AE1A2C38B0304DA2@TLVMBX01.nice.com> <2E239D6FCD033C4BAF15F386A979BF510640D1@sonusinmail02.sonusnet.com> <4E525EB8.9050405@alum.mit.edu> <2E239D6FCD033C4BAF15F386A979BF5106416E@sonusinmail02.sonusnet.com> <4E526896.60505@alum.mit.edu> <4E527645.5060807@alum.mit.edu> <4E53B75F.9090505@alum.mit.edu> <4E554F7D.8010802@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Consensus call - do we need a stream element? 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, 25 Aug 2011 07:09:40 -0000 I am for keeping it as separate object (as it today) Regards Leon -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Thursday, August 25, 2011 9:55 AM To: Paul Kyzivat Cc: Charles Eckel (eckelcu); Ravindran Parthasarathi; Leon Portman; siprec@= ietf.org Subject: Consensus call - do we need a stream element? Paul gives a good summary below of the situation concerning the need for a = stream element. Based on Paul's arguments, I (as chair) would like to make = a consensus call to keep the media stream as a separate object in the model= and a separately identifiable element in XML, rather than realising the ob= ject solely through a reference to a labelled SDP media description. Even t= hough this introduces an inefficiency for the vast majority of situations, = there are potential corner cases where it would be useful. For other aspect= s of the model and its XML realisation we have erred on the side of flexibi= lity rather than fine-tuned efficiency, and handling media stream in this w= ay would be consistent with that principle. I don't think anyone has argued= why the potential efficiency savings in taking a different approach are co= mpelling. >From my personal point of view I would have preferred to eliminate the elem= ent, but I can live with keeping it. However, I know I was not alone in pre= ferring to eliminate it. So if anyone still feels we should eliminate the stream element in XML, ple= ase say so in the next week (by 2011-09-01). The editors are due to publish -04 by the end of the month, so I would sugg= est they retain the stream element in -04. If we don't achieve consensus to= keep it, we will have to address it in -05. John John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 24 August 2011 20:23 > To: Elwell, John > Cc: Charles Eckel (eckelcu); Ravindran Parthasarathi; Leon Portman;=20 > siprec@ietf.org > Subject: Re: [siprec] Do we need a stream element? >=20 > On 8/24/11 3:52 AM, Elwell, John wrote: > > Charles, > > > >> -----Original Message----- > >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >> Sent: 23 August 2011 21:49 > >> To: Elwell, John; Paul Kyzivat > >> Cc: Ravindran Parthasarathi; Leon Portman; siprec@ietf.org > >> Subject: RE: [siprec] Do we need a stream element? > >> > >> Hi John, > >> > >> From all the examples, I do not yet see much value. The > only case in > >> which I have seen some value is the case of an SRS that is handling=20 > >> many recordings being able to detect that it is receiving multiple=20 > >> copies of the same stream and optimizing to record only a single > instance of it > >> (e.g. the multicast MoH case). For this specific case, it may be=20 > >> better to add a mechanism to not record it at all. My thought is=20 > >> SRC implementations may be smart enough to not include such > streams in the > >> RS. But that is outside the scope of SIPREC. And in > general, I am not > >> sure how likely it is that the SRCs will recognize this stream as=20 > >> being the same, and use the same ID for it. > >> Using the same MS to represent the media from a > participant before and > >> after a transfer does not seem necessary to me. As long as > the media > >> before and after the transfer is associated with the same > participant, > >> that seems sufficient to me. > > [JRE] Thanks for expressing more clearly my own thoughts. > > > >> My main hesitation with saying it is not necessary is that several=20 > >> people seem to be making arguments for why it is necessary. > >> My question > >> to them is, are you pointing out hypothetical use cases > that you agree > >> are edge cases that can be ignored for now, or are these use cases=20 > >> really of great interest to you. > > [JRE] Yes, this is what we really need to know. >=20 > I freely admit that for me these are hypothetical cases, in that I=20 > don't have an actual implementation that I am speaking for. >=20 > But IMO, while use cases are very important, corner cases are also=20 > important. It is the corner cases that define the boundaries of what=20 > you are defining. (And that is true whether you decide the corner is=20 > "in" or > "out".) >=20 > In this case, I think we are deciding whether to make a special case=20 > of MS, as contrasted to most of the other elements. The corner cases=20 > are handled it we treat it like other things, while the corner cases=20 > are excluded if we special case it. The argument for the special case=20 > is efficiency. But its not clear to me how much efficiency it affords=20 > - I'm inclined to think it isn't much. >=20 > So IMO this just adds an added argument in favor of *not* special=20 > casing MS, which would be my normal inclination in any case unless=20 > there were compelling arguments for why the optimization was needed. >=20 > Thanks, > Paul From john.elwell@siemens-enterprise.com Thu Aug 25 00:49:00 2011 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 02D0321F8AFD for ; Thu, 25 Aug 2011 00:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.164 X-Spam-Level: X-Spam-Status: No, score=-103.164 tagged_above=-999 required=5 tests=[AWL=-0.565, 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 sWmAwmk-7gZg for ; Thu, 25 Aug 2011 00:48:59 -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 5AC2B21F8AF9 for ; Thu, 25 Aug 2011 00:48:58 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 39EBF23F060F; Thu, 25 Aug 2011 09:50:10 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 25 Aug 2011 09:50:10 +0200 From: "Elwell, John" To: "Charles Eckel (eckelcu)" , Paul Kyzivat , "siprec@ietf.org" Date: Thu, 25 Aug 2011 09:50:08 +0200 Thread-Topic: [siprec] SRS-initiated INVITE Thread-Index: AcxhpLMuIJ9FkXicQtaeTNyHx7+jIwAKSxLAAAJz2YAAFnh0QAAaXGZgABaL8lA= Message-ID: References: <4E53BF55.3010309@alum.mit.edu> 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] SRS-initiated INVITE 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, 25 Aug 2011 07:49:00 -0000 Charles, But I still don't understand your earlier statement "The SRC could initiate= the CS INVITE in this case." I agree that an SRS could be asked, but some means outside SIPREC, to estab= lish recording for a conference, and given some sort of reference for the c= onference, could initiate the INVITE to the SRC (collocated with the confer= ence focus). The question is how to get the INVITE from SRS to SRC to identify the confe= rence to be recorded. Should that just be implicit in the Request-URI (the = way Request-URIs are constructed would be outside the scope of SIPREC), or = do we need something explicit?=20 I think I agree that neither Join nor Target-Dialog header fields have quit= e the right semantics for this, so if we need an explicit means of identify= ing the existing conference we would have to invent a new mechanism. John (as individual) > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]=20 > Sent: 24 August 2011 21:29 > To: Elwell, John; Paul Kyzivat; siprec@ietf.org > Subject: RE: [siprec] SRS-initiated INVITE >=20 > Please see inline. >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Wednesday, August 24, 2011 12:49 AM > > To: Charles Eckel (eckelcu); Paul Kyzivat; siprec@ietf.org > > Subject: RE: [siprec] SRS-initiated INVITE > >=20 > > Charles,, > >=20 > > > -----Original Message----- > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > Sent: 23 August 2011 22:06 > > > To: Elwell, John; Paul Kyzivat; siprec@ietf.org > > > Subject: RE: [siprec] SRS-initiated INVITE > > > > > > Hi John, > > > > > > I was envisioning a use case in which the INVITE from the SRS > > > to the SRC > > > contains a Request-URI for a call that is to be joined for the > purpose > > > of recording (e.g. a conference call). The SRS may include > > > SDP as well. > > [JRE] So this would be a different use case, for recording only a > specific call. Did you envisage > > using the Join or Target-Dialog header field to identify the CS > dialog? > >=20 > > > The SRC could initiate the CS INVITE in this case. >=20 > I do not think either of those is really appropriate for this. >=20 > > [JRE] Not sure I understand this. I had assumed, from what=20 > you said at > the start, that the purpose > > would be to record a CS already in progress, so the initial=20 > CS INVITE > would be history. I can't > > imagine why the SRS would want the SRC to establish a CS for the > purpose of recording. > >=20 > > John (as individual) >=20 > Take the case of a conference call is that is not being recorded. At > some point in time, someone decides they want to start recording the > conference. This could be done by a SIP UA that is=20 > participating in the > conference, or by the focus of the conference, acting as or=20 > interacting > with the SRC. This is already covered by our use cases. But it could > also be accomplished using some mechanism outside the scope of the > SIPREC that asks the SRS to record the conference. While the=20 > trigger is > outside the scope of SIPREC, the way the SRS initiates the RS=20 > is what I > think could be considered in scope for SIPREC. >=20 > Cheers, > Charles >=20 > =20 > >=20 > > > I'd like to hear what others think about making your proposal more > > > generic to accommodate that as well. > > > > > > Cheers, > > > Charles > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Elwell, John > > > > Sent: Tuesday, August 23, 2011 12:51 PM > > > > To: Paul Kyzivat; siprec@ietf.org > > > > Subject: Re: [siprec] SRS-initiated INVITE > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > > > > Sent: 23 August 2011 15:55 > > > > > To: siprec@ietf.org > > > > > Subject: Re: [siprec] SRS-initiated INVITE > > > > > > > > > > IIUC, the essential feature of this flow is that the R-URI > > > > > from SRS to > > > > > SRC in some way encodes the criteria for what calls the SRC > > > > > should record. > > > > > > > > > > I guess you are assuming that the manner of that encoding is > > > > > unstandardized, and hence requires a side agreement between > > > > > the SRC and > > > > > SRS. Or else it requires that the SRS be configurable to > > > > > establish an RS > > > > > to an arbitrary URI, and that the administrator is aware of > > > > > the specific > > > > > URI encoding required by the SRC to achieve the=20 > intended effect. > > > > > > > > > > While that is a bit of a stretch, I don't have any particular > > > problem > > > > > with including such an example. But this doesn't ensure > > > that any SRC > > > > > actually has this capability. > > > > [JRE] Quite so. But if the SRC has a URI that can be used > > > and the SRS > > > is configured with that URI, it > > > > should work. > > > > > > > > John > > > > > > > > > > > > > > > > > > Thanks, > > > > > Paul > > > > > > > > > > On 8/23/11 7:03 AM, Elwell, John wrote: > > > > > > (as individual) > > > > > > > > > > > > During the IETF 81 session, Andy and I agreed to propose > > > > > some text for the protocol document to cover the case of > > > > > SRS-initiated INVITE in more detail. This is our proposal: > > > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > > > > > The following is a sample call flow that shows the SRS > > > > > establishing a recording session towards the SRC. The most > > > > > likely application of this is for persistent recording, where > > > > > the SRS does not need to have prior knowledge of particular > > > > > CSs that need to be recorded but simply requires to record > > > > > all CSs with certain characteristics (e.g., involving a > > > > > particular user). Also it is more likely to arise when the > > > > > SRC is located at a B2BUA, rather than at a UA, and therefore > > > > > the SRS does not need to identify a particular UA as the > > > > > target of the INVITE request. > > > > > > > > > > > > > > > > > > UA A SRC UA B > > > > > SRS > > > > > > | | (1) RS INVITE without SDP > > > | > > > > > > | > > > |<---------------------------------------------| > > > > > > | | (2) OK with SDP > > > | > > > > > > | > > > |--------------------------------------------->| > > > > > > | | (3) ACK with SDP > > > | > > > > > > | > > > |<---------------------------------------------| > > > > > > |(4)CS INVITE | | > > > | > > > > > > |------------->| | > > > | > > > > > > | |(5)CS INVITE | > > > | > > > > > > | |---------------------->| > > > | > > > > > > | | (6)OK | > > > | > > > > > > | |<----------------------| > > > | > > > > > > | (7)OK | | > > > | > > > > > > |<-------------| | > > > | > > > > > > | |(8)RS UPDATE with SDP and metadata > > > | > > > > > > | > > > |--------------------------------------------->| > > > > > > | | (9)OK with SDP > > > | > > > > > > | > > > |<---------------------------------------------| > > > > > > |(10)CS RTP | | > > > | > > > > > > |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > > | > > > > > > |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|<=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| > > > | > > > > > > | |(11)RS RTP | > > > | > > > > > > | > > > |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > > > > > | > > > |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > > > > > |(12)CS BYE | | > > > | > > > > > > |------------->| | > > > | > > > > > > | |(13)CS BYE | > > > | > > > > > > | |---------------------->| > > > | > > > > > > | | (14) CS OK | > > > | > > > > > > | |<----------------------| > > > | > > > > > > | (15)OK | | > > > | > > > > > > |<-------------| | > > > | > > > > > > | |(16)UPDATE with SDP and metadata > > > > > | | > > > > > > | > > > |--------------------------------------------->| > > > > > > | | (17)OK with SDP > > > | > > > > > > | > > > |<---------------------------------------------| > > > > > > | | | > > > | > > > > > > > > > > > > Figure 2: Persistent Recording Call Flow, RS > > > > > Established by SRS > > > > > > > > > > > > The initial INVITE request for establishing the RS (1) has > > > > > a Request-URI that identifies the SRC and instructs the SRC > > > > > what to record (e.g., all CSs involving a particular user). > > > > > The SDP offer from the SRC (2) might have no media or might > > > > > establish inactive media in anticipation of future=20 > requirements. > > > > > > > > > > > > The first UPDATE request (8) occurs on establishment of a > > > > > recordable CS. It includes metadata describing the CS and, if > > > > > necessary, includes a new SDP offer to establish or modify > > > > > media streams needed for recording that CS. > > > > > > > > > > > > The second UPDATE request (16) occurs on termination of a > > > > > recordable CS. It includes metadata indicating termination of > > > > > the CS and might include a new SDP offer changing media > > > > > streams that are no longer wanted to disabled or inactive. > > > > > Because this is persistent recording, the RS would typically > > > > > remain in place awaiting other recordable CSs. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > > > Other places in the document will also need some changes, > > > > > but I would like first to see if we can get agreement on the > > > > > general principle and on inclusion of this scenario in section > 4. > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > John Elwell > > > > > > Tel: +44 1908 817801 (office and mobile) > > > > > > Email: john.elwell@siemens-enterprise.com > > > > > > http://www.siemens-enterprise.com/uk/ > > > > > > > > > > > > Siemens Enterprise Communications Limited. > > > > > > Registered office: Brickhill Street, Willen Lake, Milton > > > > > Keynes, MK15 0DJ. > > > > > > Registered No: 5903714, England. > > > > > > > > > > > > Siemens Enterprise Communications Limited is a Trademark > > > > > Licensee of Siemens AG. > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > siprec mailing 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 Thu Aug 25 01:14:44 2011 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 7420121F8B11 for ; Thu, 25 Aug 2011 01:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnXXnZdTfplU for ; Thu, 25 Aug 2011 01:14:43 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5D15521F8B10 for ; Thu, 25 Aug 2011 01:14:43 -0700 (PDT) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p7P8GKbo004321; Thu, 25 Aug 2011 04:16:20 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Aug 2011 04:08:14 -0400 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, 25 Aug 2011 13:38:11 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51064302@sonusinmail02.sonusnet.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38B041DA8E@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus call - do we need a stream element? Thread-Index: AcxikzFCm1v0d3XPRkWipEktmk+/tAAXu/9gAAD7tlAAAflnQA== References: <4E402C2F.1080103@alum.mit.edu><07465C1D981ABC41A344374066AE1A2C38B0304DA2@TLVMBX01.nice.com> <2E239D6FCD033C4BAF15F386A979BF510640D1@sonusinmail02.sonusnet.com> <4E525EB8.9050405@alum.mit.edu> <2E239D6FCD033C4BAF15F386A979BF5106416E@sonusinmail02.sonusnet.com> <4E526896.60505@alum.mit.edu> <4E527645.5060807@alum.mit.edu> <4E53B75F.9090505@alum.mit.edu> <4E554F7 D.801080 2@alum.mit.e du> <07465C1D981ABC41A344374066AE1A2C38B041DA8E@TLVMBX01.nice.com> From: "Ravindran Parthasarathi" To: "Leon Portman" , "Elwell, John" , "Paul Kyzivat" X-OriginalArrivalTime: 25 Aug 2011 08:08:14.0590 (UTC) FILETIME=[23A171E0:01CC62FE] Cc: siprec@ietf.org Subject: Re: [siprec] Consensus call - do we need a stream element? 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, 25 Aug 2011 08:14:44 -0000 +1 Thanks Partha >-----Original Message----- >From: Leon Portman [mailto:Leon.Portman@nice.com] >Sent: Thursday, August 25, 2011 12:41 PM >To: Elwell, John; Paul Kyzivat >Cc: Charles Eckel (eckelcu); Ravindran Parthasarathi; siprec@ietf.org >Subject: RE: Consensus call - do we need a stream element? > >I am for keeping it as separate object (as it today) > >Regards > >Leon > >-----Original Message----- >From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >Sent: Thursday, August 25, 2011 9:55 AM >To: Paul Kyzivat >Cc: Charles Eckel (eckelcu); Ravindran Parthasarathi; Leon Portman; >siprec@ietf.org >Subject: Consensus call - do we need a stream element? > >Paul gives a good summary below of the situation concerning the need for >a stream element. Based on Paul's arguments, I (as chair) would like to >make a consensus call to keep the media stream as a separate object in >the model and a separately identifiable element in XML, rather than >realising the object solely through a reference to a labelled SDP media >description. Even though this introduces an inefficiency for the vast >majority of situations, there are potential corner cases where it would >be useful. For other aspects of the model and its XML realisation we >have erred on the side of flexibility rather than fine-tuned efficiency, >and handling media stream in this way would be consistent with that >principle. I don't think anyone has argued why the potential efficiency >savings in taking a different approach are compelling. > >From my personal point of view I would have preferred to eliminate the >element, but I can live with keeping it. However, I know I was not alone >in preferring to eliminate it. > >So if anyone still feels we should eliminate the stream element in XML, >please say so in the next week (by 2011-09-01). > >The editors are due to publish -04 by the end of the month, so I would >suggest they retain the stream element in -04. If we don't achieve >consensus to keep it, we will have to address it in -05. > >John > >John Elwell >Tel: +44 1908 817801 (office and mobile) >Email: john.elwell@siemens-enterprise.com >http://www.siemens-enterprise.com/uk/ > >Siemens Enterprise Communications Limited. >Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 >0DJ. >Registered No: 5903714, England. > >Siemens Enterprise Communications Limited is a Trademark Licensee of >Siemens AG. > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 24 August 2011 20:23 >> To: Elwell, John >> Cc: Charles Eckel (eckelcu); Ravindran Parthasarathi; Leon Portman; >> siprec@ietf.org >> Subject: Re: [siprec] Do we need a stream element? >> >> On 8/24/11 3:52 AM, Elwell, John wrote: >> > Charles, >> > >> >> -----Original Message----- >> >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >> >> Sent: 23 August 2011 21:49 >> >> To: Elwell, John; Paul Kyzivat >> >> Cc: Ravindran Parthasarathi; Leon Portman; siprec@ietf.org >> >> Subject: RE: [siprec] Do we need a stream element? >> >> >> >> Hi John, >> >> >> >> From all the examples, I do not yet see much value. The >> only case in >> >> which I have seen some value is the case of an SRS that is handling >> >> many recordings being able to detect that it is receiving multiple >> >> copies of the same stream and optimizing to record only a single >> instance of it >> >> (e.g. the multicast MoH case). For this specific case, it may be >> >> better to add a mechanism to not record it at all. My thought is >> >> SRC implementations may be smart enough to not include such >> streams in the >> >> RS. But that is outside the scope of SIPREC. And in >> general, I am not >> >> sure how likely it is that the SRCs will recognize this stream as >> >> being the same, and use the same ID for it. >> >> Using the same MS to represent the media from a >> participant before and >> >> after a transfer does not seem necessary to me. As long as >> the media >> >> before and after the transfer is associated with the same >> participant, >> >> that seems sufficient to me. >> > [JRE] Thanks for expressing more clearly my own thoughts. >> > >> >> My main hesitation with saying it is not necessary is that several >> >> people seem to be making arguments for why it is necessary. >> >> My question >> >> to them is, are you pointing out hypothetical use cases >> that you agree >> >> are edge cases that can be ignored for now, or are these use cases >> >> really of great interest to you. >> > [JRE] Yes, this is what we really need to know. >> >> I freely admit that for me these are hypothetical cases, in that I >> don't have an actual implementation that I am speaking for. >> >> But IMO, while use cases are very important, corner cases are also >> important. It is the corner cases that define the boundaries of what >> you are defining. (And that is true whether you decide the corner is >> "in" or >> "out".) >> >> In this case, I think we are deciding whether to make a special case >> of MS, as contrasted to most of the other elements. The corner cases >> are handled it we treat it like other things, while the corner cases >> are excluded if we special case it. The argument for the special case >> is efficiency. But its not clear to me how much efficiency it affords >> - I'm inclined to think it isn't much. >> >> So IMO this just adds an added argument in favor of *not* special >> casing MS, which would be my normal inclination in any case unless >> there were compelling arguments for why the optimization was needed. >> >> Thanks, >> Paul From rmohanr@cisco.com Thu Aug 25 01:30:39 2011 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 86EDA21F84D6 for ; Thu, 25 Aug 2011 01:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.117 X-Spam-Level: X-Spam-Status: No, score=-10.117 tagged_above=-999 required=5 tests=[AWL=0.482, 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 i+VpP9fa6wNN for ; Thu, 25 Aug 2011 01:30:38 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0106621F84FD for ; Thu, 25 Aug 2011 01:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=6029; q=dns/txt; s=iport; t=1314261111; x=1315470711; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=9BaetUcpW8TLBw7vJhkUgvrZYJRlQyRcEUeMOU5J1YM=; b=PgCcEc63pKU7Hmo1TqmyhGZBQkpEdVq2eN4FeSiQKOA/BI+M0JD2SUGF qjSnIk5ZDsVI01c1erzcqqswJ2HSiTSIPc2sxvEVANmhhUIXWpRwl3cjb J4Hriz9medakCrIJxFiYdly2SnuFr69wN3N/eVE2vQkArnZ+FO6DFFZHc M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgAAC8IVk5Io8US/2dsb2JhbABCDpgbj1h3gUABAQEBAwEBAQ8BHQo0CwwEAgEIEQQBAQEKBhcBBgEmHwkIAQEEAQkBCAgah1SbHAGfBoVsYASHX5BQiy1A X-IronPort-AV: E=Sophos;i="4.68,280,1312156800"; d="scan'208";a="51943324" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 25 Aug 2011 08:31:32 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7P8VVR4032054; Thu, 25 Aug 2011 08:31:31 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Aug 2011 14:01:31 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Aug 2011 14:01:28 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD076C24EC@XMB-BGL-417.cisco.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38B041DA8E@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Consensus call - do we need a stream element? Thread-Index: AcxikzFCm1v0d3XPRkWipEktmk+/tAAXu/9gAAD7tlAAAtNrUA== References: <4E402C2F.1080103@alum.mit.edu><07465C1D981ABC41A344374066AE1A2C38B0304DA2@TLVMBX01.nice.com><2E239D6FCD033C4BAF15F386A979BF510640D1@sonusinmail02.sonusnet.com><4E525EB8.9050405@alum.mit.edu><2E239D6FCD033C4BAF15F386A979BF5106416E@sonusinmail02.sonusnet.com><4E526896.60505@alum.mit.edu><4E527645.5060807@alum.mit.edu><4E53B75F.9090505@alum.mit.edu><4E554F7D.8010802@alum .mit.edu > <07465C1D981ABC41A344374066AE1A2C38B041DA8E@TLVMBX01.nice.com> From: "Ram Mohan R (rmohanr)" To: "Leon Portman" , "Elwell, John" , "Paul Kyzivat" X-OriginalArrivalTime: 25 Aug 2011 08:31:31.0640 (UTC) FILETIME=[64565B80:01CC6301] Cc: siprec@ietf.org Subject: Re: [siprec] Consensus call - do we need a stream element? 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, 25 Aug 2011 08:30:39 -0000 +1 Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Leon Portman > Sent: Thursday, August 25, 2011 12:41 PM > To: Elwell, John; Paul Kyzivat > Cc: siprec@ietf.org > Subject: Re: [siprec] Consensus call - do we need a stream element? >=20 > I am for keeping it as separate object (as it today) >=20 > Regards >=20 > Leon >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, August 25, 2011 9:55 AM > To: Paul Kyzivat > Cc: Charles Eckel (eckelcu); Ravindran Parthasarathi; Leon Portman; > siprec@ietf.org > Subject: Consensus call - do we need a stream element? >=20 > Paul gives a good summary below of the situation concerning the need > for a stream element. Based on Paul's arguments, I (as chair) would > like to make a consensus call to keep the media stream as a separate > object in the model and a separately identifiable element in XML, > rather than realising the object solely through a reference to a > labelled SDP media description. Even though this introduces an > inefficiency for the vast majority of situations, there are potential > corner cases where it would be useful. For other aspects of the model > and its XML realisation we have erred on the side of flexibility rather > than fine-tuned efficiency, and handling media stream in this way would > be consistent with that principle. I don't think anyone has argued why > the potential efficiency savings in taking a different approach are > compelling. >=20 > From my personal point of view I would have preferred to eliminate the > element, but I can live with keeping it. However, I know I was not > alone in preferring to eliminate it. >=20 > So if anyone still feels we should eliminate the stream element in XML, > please say so in the next week (by 2011-09-01). >=20 > The editors are due to publish -04 by the end of the month, so I would > suggest they retain the stream element in -04. If we don't achieve > consensus to keep it, we will have to address it in -05. >=20 > John >=20 > John Elwell > Tel: +44 1908 817801 (office and mobile) > Email: john.elwell@siemens-enterprise.com > http://www.siemens-enterprise.com/uk/ >=20 > Siemens Enterprise Communications Limited. > Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 > 0DJ. > Registered No: 5903714, England. >=20 > Siemens Enterprise Communications Limited is a Trademark Licensee of > Siemens AG. >=20 >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > Sent: 24 August 2011 20:23 > > To: Elwell, John > > Cc: Charles Eckel (eckelcu); Ravindran Parthasarathi; Leon Portman; > > siprec@ietf.org > > Subject: Re: [siprec] Do we need a stream element? > > > > On 8/24/11 3:52 AM, Elwell, John wrote: > > > Charles, > > > > > >> -----Original Message----- > > >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > >> Sent: 23 August 2011 21:49 > > >> To: Elwell, John; Paul Kyzivat > > >> Cc: Ravindran Parthasarathi; Leon Portman; siprec@ietf.org > > >> Subject: RE: [siprec] Do we need a stream element? > > >> > > >> Hi John, > > >> > > >> From all the examples, I do not yet see much value. The > > only case in > > >> which I have seen some value is the case of an SRS that is > handling > > >> many recordings being able to detect that it is receiving multiple > > >> copies of the same stream and optimizing to record only a single > > instance of it > > >> (e.g. the multicast MoH case). For this specific case, it may be > > >> better to add a mechanism to not record it at all. My thought is > > >> SRC implementations may be smart enough to not include such > > streams in the > > >> RS. But that is outside the scope of SIPREC. And in > > general, I am not > > >> sure how likely it is that the SRCs will recognize this stream as > > >> being the same, and use the same ID for it. > > >> Using the same MS to represent the media from a > > participant before and > > >> after a transfer does not seem necessary to me. As long as > > the media > > >> before and after the transfer is associated with the same > > participant, > > >> that seems sufficient to me. > > > [JRE] Thanks for expressing more clearly my own thoughts. > > > > > >> My main hesitation with saying it is not necessary is that several > > >> people seem to be making arguments for why it is necessary. > > >> My question > > >> to them is, are you pointing out hypothetical use cases > > that you agree > > >> are edge cases that can be ignored for now, or are these use cases > > >> really of great interest to you. > > > [JRE] Yes, this is what we really need to know. > > > > I freely admit that for me these are hypothetical cases, in that I > > don't have an actual implementation that I am speaking for. > > > > But IMO, while use cases are very important, corner cases are also > > important. It is the corner cases that define the boundaries of what > > you are defining. (And that is true whether you decide the corner is > > "in" or > > "out".) > > > > In this case, I think we are deciding whether to make a special case > > of MS, as contrasted to most of the other elements. The corner cases > > are handled it we treat it like other things, while the corner cases > > are excluded if we special case it. The argument for the special case > > is efficiency. But its not clear to me how much efficiency it affords > > - I'm inclined to think it isn't much. > > > > So IMO this just adds an added argument in favor of *not* special > > casing MS, which would be my normal inclination in any case unless > > there were compelling arguments for why the optimization was needed. > > > > Thanks, > > Paul > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Thu Aug 25 07:53:55 2011 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 50C6F21F884C for ; Thu, 25 Aug 2011 07:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.153 X-Spam-Level: X-Spam-Status: No, score=-103.153 tagged_above=-999 required=5 tests=[AWL=-0.554, 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 GlSsXAgyXLBc for ; Thu, 25 Aug 2011 07:53:54 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB9521F8A56 for ; Thu, 25 Aug 2011 07:53:53 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id C99E71EB84F3 for ; Thu, 25 Aug 2011 16:55:06 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 25 Aug 2011 16:55:06 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Thu, 25 Aug 2011 16:55:05 +0200 Thread-Topic: Comments on draft-ietf-siprec-protocol-00 Thread-Index: AcxjNvmwRzTTiCXWTFmG2b7c2r125g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Comments on 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: Thu, 25 Aug 2011 14:53:55 -0000 I have read -00 and I believe it needs some refactoring to change from a pr= oposal to a specification - it is in limbo between the two at present. Part= icular comments are as follows: 1. The Abstract should say something about the protocol being based on SIP/= SDP/RTP. On the other hand, I see no need to introduce terms like SRC and = SRS in the Abstract. Something like: "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 to a = recording device." 2. The Introduction needs structuring better. I think it needs to cover the= following points (in sequence): - State what we are trying to achieve (i.e., delivering real-time media and= metadata from a CS to a recording device. - State that we are using SIP/SDP/RTP for this purpose. - State that SIP is used to establish an RS between an SRC on the path of t= he CS to an SRS at the recording device, in accordance with the architectur= e in [arch]. - State that SIP is also used to deliver metadata, as specified in [metadat= a] to the SRS. - State that the protocol satisfies the requirements in RFC6341. - I am not a big fan of having a statement about the structure of the docum= ent, since it in some respects duplicates the table of contents, but I gues= s it does no harm. Ensure that acronyms are expanded on first use.=20 3. I suspect the Scope section (3) requires more work. For example: - Make it clear that record-aware UAs are UAs participating in the CS. - Recording policies not only determine which CSs are to be recorded, but a= lso whether parts of a CS are to be recorded. - Delivering on-real-time media is out of scope. - Policies governing how CS users are made aware of recording are out of sc= ope. - Acquiring >>additional<< metadata through non-SIP means - I think we are = only talking about additional metadata, not a replacement for the metadata = delivered over SIP. 4. Section 4.1 needs a little attention to avoid confusing SRC functionalit= y and B2BUA or UA functionality. For example: "When the SRC is deployed as a B2BUA, the SRC can route call requests from = UA(A) to UA(B)". I would contend that the B2BUA routes call requests from A to B. The SRC is= merely an add-on that does the recording bit. Also it says: "the SRC may bridge the media between UA(A) and UA(B)." I would suggest expressing it as "the SRC can cause the B2BUA to bridge the= media..." 5. Section 4.2 describes the use of REFER to a conference focus to get it t= o establish an RS. How does the conference focus know, on receipt of the RE= FER request, that the resulting INVITE request is for the purpose of record= ing? In addition, I see no mention of REFER in the rest of the document, so= is this section really relevant? I agree an SRC could be located at a conf= erence focus, but establishment of RSs can be left as local policy for the = SRC (or the SRS, in the case of SRS-initiated). This is effectively the cas= e for the B2BUA case, so why not for the conference focus case? 6. Section 4.3 is a little bit back-to-front, in the sense that it starts o= ff by talking about exceptions (metadata information that is delivered by S= DP rather than in metadata XML) - it would be better to describe the XML de= livery mechanism first, and then point out that certain metadata is not inc= luded in XML since it is present in SDP. But be careful not to duplicate ma= terial that is in the metadata draft - maybe we don't even need to mention = the exception in the protocol document. Also I think we should be clearer about the conditions when a snapshot requ= est is appropriate, as discussed recently. 6. Section 5 has the title "SIP Extensions for Recording Session", but the = first part (prior to 5.1) does not really talk about extensions but talks a= bout how to implement existing SIP capabilities. For example, the paragraph= about the From header field. Not sure whether the "must" here is meant to = be a "MUST". What about PAI?=20 The paragraph about pre-allocating a recorded media stream (i.e., an RS med= ia stream) has implications beyond just SIP, e.g., on keeping it alive unti= l needed, on what to do when one CS finishes. Also it should perhaps not ju= st talk about a single media stream, but one per medium for which there is = an anticipated need for recording and for which clipping would be a problem= . I think a lot more needs to be said, but it doesn't really fit under "SIP= Extensions". The last paragraph talks about recorded media streams from multiple CSs, bu= t not about multiple recorded media streams from a single CS. Informational material can probably go in section 4, but we need to think a= bout how to organize the normative stuff, given that it can impact SIP, SDP= and RTP. Also, I would like to see any normative procedures sub-divided un= to procedures at an SRC and procedures at an SRS. I think we need to be careful with our terminology to do with media streams= - whether we are talking about a CS media stream, an RS media stream, or a= metadata media stream object (which, according to recent discussions, is c= onstrained to be neither just a CS media stream nor just an RS media stream= ). 7. Section 5.1.1. The middle paragraph is background to why we have made a = decision - this shouldn't remain in the final deliverable. In both 5.1.1 an= d 5.1.2 we are missing normative procedures for the SRC and SRS, e.g., I th= ink there need to be MUSTs concerning inclusion of the relevant tag in one'= s Contact header fields, and possibly MUSTs concerning receipt of the other= one in received Contact header fields. 8. Section 5.3 "SDP handling" does not seem to fit in section 5 "SIP Extens= ions for Recording Session". The section contains a number of lower case musts, shoulds and mays, and I = think some of these should be normative, others not. We must be careful not= to make normative statements that repeat normative statements in other spe= cifications (e.g., RFC 3264, 4566), or worse still contradict existing norm= ative provisions. On the other hand we might need normative statements that= go beyond what are in existing RFCs, i.e., closing options. Also there is = some use of present tense, e.g."To remove a recorded media stream from the = recording session, send a reINVITE and set the port to zero in the m=3D line." Again terminology around media streams needs to be considered very carefull= y, Also the description around the use of labels needs some careful attent= ion to wording. For example: "Note that a participant may have multiple streams (audio and video) and each stream is labeled separately." This could be interpreted that streams are specific to particular participa= nts, but generally CS streams relate to a CS and any number of participants= in the CS can contribute to or receive a given stream. 9. Section 5.5: "The label attribute contains a reference to the rest of the metadata information." Not exactly. A label attribute within an RS SDP media description is a mean= s by which a media stream element in metadata XML can reference that media = description and hence identify the RS media stream used for conveying that = media stream to the SRS. (But you can see here how we have a problem with media stream terminology). "For all basic metadata information such as communication session, participants and call identifiers, they can be included in the initial INVITE request sent by the SRC." This is incorrect for persistent recording or for any other situation where= a single RS is used to record multiple CSs where not all CSs and/or not al= l participants exist at the time the RS is established. "Metadata can be included as content in the INVITE or UPDATE request." Which particular UPDATE request is this? "A new "disposition-type" of Content-Disposition is defined for this purpose and the value is "recording-session"." This content disposition value is not just defined for this purpose (the in= itial INVITE, which is the subject of this paragraph). It is also to be use= d in re-INVITEs, later, i.e., it is applicable to any message in which meta= data is to be conveyed. Also why do we mention the content-disposition valu= e without mentioning the content-type value? "Since there can only be a single INVITE or UPDATE transaction happening at a time within a SIP dialog, using sequence number CSeq in the dialog can be a reliable way for the SRS to identify the receipt of the next metadata update." Because of the existence of B2BUAs on the RS signalling path, I doubt we ca= n claim that Cseq is reliable. The last paragraph talks about metadata snapshots, yet we have not yet intr= oduced the concept of partial versus full metadata. 10. Section 5.6. I rather doubt the need for such complexity in the body of a snapshot reque= st. In particular, I find the use of the term "header" confusing when talki= ng about a body part of a SIP message (particular as a Reason header field = exists in SIP as well). Where is the ABNF for "extension-header" defined? 11. Section 5.7. I think this needs to mention keep-alives. It also needs to make it clear t= hat pausing could be because of pausing a recording during a CS or pausing = because a CS has finished, or a particular CS media stream has finished. Or= at least that is my assumption. Do we need to mention disabling media when finished with? For example, as t= he number of active RS media streams grows with more parallel CSs and media= , and then shrinks as these terminate, do we necessarily need to change the= m all to inactive and keep the streams alive, thereby wasting resources suc= h as NAT ports, SRS ports, TURN servers, etc.? Concerning the last paragraph about mute, if all participants contributing = to a media stream have invoked mute, is this not good reason to change the = RS media stream to inactive? In any case, do we need to say something about= keep-alive in this situation? 12. Section 6 "Extensions for Recording-Aware User Agents" - I would like t= o see normative procedures sub-divided into procedures at an SRC and proced= ures at a recording-aware UA. In 6.1.1: " When a UA has not indicated that it is recording aware, an SRC MUST provide recording indications, where SRC is required to do so based on policies, through other means such as playing a tone inband" I think it also needs to be stated that the fact that a UA claims to be rec= ording aware does not necessarily obviate the need for providing indication= s of recording through other means, particularly where a particular message= needs to be conveyed. A recording-aware UA can, however, supplement any ot= her indication, e.g, by tailoring to the needs of the user. 13. I suspect there is more we will want to say on security, and probably p= rivacy too, but I haven't given it much thought. Perhaps a reference to the= considerations in RFC 6341 might be a start. John (as individual) John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. From eckelcu@cisco.com Fri Aug 26 14:15:28 2011 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 06EB721F8C19 for ; Fri, 26 Aug 2011 14:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.759 X-Spam-Level: X-Spam-Status: No, score=-2.759 tagged_above=-999 required=5 tests=[AWL=-0.160, 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 tRgn5ijwSoHw for ; Fri, 26 Aug 2011 14:15:26 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 873C021F8B66 for ; Fri, 26 Aug 2011 14:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=13280; q=dns/txt; s=iport; t=1314393404; x=1315603004; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=GuoNl9ixJQLyA9XRGOG6Sjzi3kJMj6MwCgzXjWj0+4o=; b=RL8lhaqDUnQAxdofJ5La0e/pJivQ7NiUeNz3sBVjUHb8FBJpObymRFI5 7NS3a1hV+f//Zpf372jO9RXtGz3uy2C3PbUSkDjEA5pKf9EZrRmkUOBYr ErrgSUQCFiCCUskzpsE+xVgc6Bx7yUT4HdkgLqK97YIss3xmMB36D0GzW U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArIAAH0MWE6rRDoH/2dsb2JhbAA5Cg6YOo9ed4FAAQEBAQIBAQEBDwEUCQouBhAHBAIBCBEEAQEBCgYXAQYBJh8JCAIEARIIGodQBJtQAZ8YgyiCRGAEh2KQTosyWA X-IronPort-AV: E=Sophos;i="4.68,287,1312156800"; d="scan'208";a="16940835" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-1.cisco.com with ESMTP; 26 Aug 2011 21:16:43 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7QLGW99020357; Fri, 26 Aug 2011 21:16:42 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 26 Aug 2011 14:16:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Aug 2011 14:16:10 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] SRS-initiated INVITE Thread-Index: AcxhpLMuIJ9FkXicQtaeTNyHx7+jIwAKSxLAAAJz2YAAFnh0QAAaXGZgABaL8lAAT9P9YA== References: <4E53BF55.3010309@alum.mit.edu> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , "Paul Kyzivat" , X-OriginalArrivalTime: 26 Aug 2011 21:16:12.0092 (UTC) FILETIME=[61A17FC0:01CC6435] Subject: Re: [siprec] SRS-initiated INVITE 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, 26 Aug 2011 21:15:28 -0000 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, August 25, 2011 12:50 AM > To: Charles Eckel (eckelcu); Paul Kyzivat; siprec@ietf.org > Subject: RE: [siprec] SRS-initiated INVITE >=20 > Charles, >=20 > But I still don't understand your earlier statement "The SRC could initiate the CS INVITE in this > case." >=20 > I agree that an SRS could be asked, but some means outside SIPREC, to establish recording for a > conference, and given some sort of reference for the conference, could initiate the INVITE to the SRC > (collocated with the conference focus). >=20 > The question is how to get the INVITE from SRS to SRC to identify the conference to be recorded. > Should that just be implicit in the Request-URI (the way Request-URIs are constructed would be outside > the scope of SIPREC), or do we need something explicit? The Request URI could be used, but if others agree this is a worthwhile use case, I think it would be more appropriate to define something explicit. Taking this to the extreme, the explicit information could be in the form of metadata from the SRS to the SRC, providing as much information about the intended recording as the SRS knows. Cheers, Charles =20 =20 > I think I agree that neither Join nor Target-Dialog header fields have quite the right semantics for > this, so if we need an explicit means of identifying the existing conference we would have to invent a > new mechanism. >=20 > John (as individual) >=20 >=20 >=20 > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > Sent: 24 August 2011 21:29 > > To: Elwell, John; Paul Kyzivat; siprec@ietf.org > > Subject: RE: [siprec] SRS-initiated INVITE > > > > Please see inline. > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Wednesday, August 24, 2011 12:49 AM > > > To: Charles Eckel (eckelcu); Paul Kyzivat; siprec@ietf.org > > > Subject: RE: [siprec] SRS-initiated INVITE > > > > > > Charles,, > > > > > > > -----Original Message----- > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > Sent: 23 August 2011 22:06 > > > > To: Elwell, John; Paul Kyzivat; siprec@ietf.org > > > > Subject: RE: [siprec] SRS-initiated INVITE > > > > > > > > Hi John, > > > > > > > > I was envisioning a use case in which the INVITE from the SRS > > > > to the SRC > > > > contains a Request-URI for a call that is to be joined for the > > purpose > > > > of recording (e.g. a conference call). The SRS may include > > > > SDP as well. > > > [JRE] So this would be a different use case, for recording only a > > specific call. Did you envisage > > > using the Join or Target-Dialog header field to identify the CS > > dialog? > > > > > > > The SRC could initiate the CS INVITE in this case. > > > > I do not think either of those is really appropriate for this. > > > > > [JRE] Not sure I understand this. I had assumed, from what > > you said at > > the start, that the purpose > > > would be to record a CS already in progress, so the initial > > CS INVITE > > would be history. I can't > > > imagine why the SRS would want the SRC to establish a CS for the > > purpose of recording. > > > > > > John (as individual) > > > > Take the case of a conference call is that is not being recorded. At > > some point in time, someone decides they want to start recording the > > conference. This could be done by a SIP UA that is > > participating in the > > conference, or by the focus of the conference, acting as or > > interacting > > with the SRC. This is already covered by our use cases. But it could > > also be accomplished using some mechanism outside the scope of the > > SIPREC that asks the SRS to record the conference. While the > > trigger is > > outside the scope of SIPREC, the way the SRS initiates the RS > > is what I > > think could be considered in scope for SIPREC. > > > > Cheers, > > Charles > > > > > > > > > > > I'd like to hear what others think about making your proposal more > > > > generic to accommodate that as well. > > > > > > > > Cheers, > > > > Charles > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On > > > > Behalf Of Elwell, John > > > > > Sent: Tuesday, August 23, 2011 12:51 PM > > > > > To: Paul Kyzivat; siprec@ietf.org > > > > > Subject: Re: [siprec] SRS-initiated INVITE > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > > > > > Sent: 23 August 2011 15:55 > > > > > > To: siprec@ietf.org > > > > > > Subject: Re: [siprec] SRS-initiated INVITE > > > > > > > > > > > > IIUC, the essential feature of this flow is that the R-URI > > > > > > from SRS to > > > > > > SRC in some way encodes the criteria for what calls the SRC > > > > > > should record. > > > > > > > > > > > > I guess you are assuming that the manner of that encoding is > > > > > > unstandardized, and hence requires a side agreement between > > > > > > the SRC and > > > > > > SRS. Or else it requires that the SRS be configurable to > > > > > > establish an RS > > > > > > to an arbitrary URI, and that the administrator is aware of > > > > > > the specific > > > > > > URI encoding required by the SRC to achieve the > > intended effect. > > > > > > > > > > > > While that is a bit of a stretch, I don't have any particular > > > > problem > > > > > > with including such an example. But this doesn't ensure > > > > that any SRC > > > > > > actually has this capability. > > > > > [JRE] Quite so. But if the SRC has a URI that can be used > > > > and the SRS > > > > is configured with that URI, it > > > > > should work. > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > Paul > > > > > > > > > > > > On 8/23/11 7:03 AM, Elwell, John wrote: > > > > > > > (as individual) > > > > > > > > > > > > > > During the IETF 81 session, Andy and I agreed to propose > > > > > > some text for the protocol document to cover the case of > > > > > > SRS-initiated INVITE in more detail. This is our proposal: > > > > > > > > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > The following is a sample call flow that shows the SRS > > > > > > establishing a recording session towards the SRC. The most > > > > > > likely application of this is for persistent recording, where > > > > > > the SRS does not need to have prior knowledge of particular > > > > > > CSs that need to be recorded but simply requires to record > > > > > > all CSs with certain characteristics (e.g., involving a > > > > > > particular user). Also it is more likely to arise when the > > > > > > SRC is located at a B2BUA, rather than at a UA, and therefore > > > > > > the SRS does not need to identify a particular UA as the > > > > > > target of the INVITE request. > > > > > > > > > > > > > > > > > > > > > UA A SRC UA B > > > > > > SRS > > > > > > > | | (1) RS INVITE without SDP > > > > | > > > > > > > | > > > > |<---------------------------------------------| > > > > > > > | | (2) OK with SDP > > > > | > > > > > > > | > > > > |--------------------------------------------->| > > > > > > > | | (3) ACK with SDP > > > > | > > > > > > > | > > > > |<---------------------------------------------| > > > > > > > |(4)CS INVITE | | > > > > | > > > > > > > |------------->| | > > > > | > > > > > > > | |(5)CS INVITE | > > > > | > > > > > > > | |---------------------->| > > > > | > > > > > > > | | (6)OK | > > > > | > > > > > > > | |<----------------------| > > > > | > > > > > > > | (7)OK | | > > > > | > > > > > > > |<-------------| | > > > > | > > > > > > > | |(8)RS UPDATE with SDP and metadata > > > > | > > > > > > > | > > > > |--------------------------------------------->| > > > > > > > | | (9)OK with SDP > > > > | > > > > > > > | > > > > |<---------------------------------------------| > > > > > > > |(10)CS RTP | | > > > > | > > > > > > > = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > > > | > > > > > > > = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| > > > > | > > > > > > > | |(11)RS RTP | > > > > | > > > > > > > | > > > > = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > > > > > > | > > > > = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > > > > > > |(12)CS BYE | | > > > > | > > > > > > > |------------->| | > > > > | > > > > > > > | |(13)CS BYE | > > > > | > > > > > > > | |---------------------->| > > > > | > > > > > > > | | (14) CS OK | > > > > | > > > > > > > | |<----------------------| > > > > | > > > > > > > | (15)OK | | > > > > | > > > > > > > |<-------------| | > > > > | > > > > > > > | |(16)UPDATE with SDP and metadata > > > > > > | | > > > > > > > | > > > > |--------------------------------------------->| > > > > > > > | | (17)OK with SDP > > > > | > > > > > > > | > > > > |<---------------------------------------------| > > > > > > > | | | > > > > | > > > > > > > > > > > > > > Figure 2: Persistent Recording Call Flow, RS > > > > > > Established by SRS > > > > > > > > > > > > > > The initial INVITE request for establishing the RS (1) has > > > > > > a Request-URI that identifies the SRC and instructs the SRC > > > > > > what to record (e.g., all CSs involving a particular user). > > > > > > The SDP offer from the SRC (2) might have no media or might > > > > > > establish inactive media in anticipation of future > > requirements. > > > > > > > > > > > > > > The first UPDATE request (8) occurs on establishment of a > > > > > > recordable CS. It includes metadata describing the CS and, if > > > > > > necessary, includes a new SDP offer to establish or modify > > > > > > media streams needed for recording that CS. > > > > > > > > > > > > > > The second UPDATE request (16) occurs on termination of a > > > > > > recordable CS. It includes metadata indicating termination of > > > > > > the CS and might include a new SDP offer changing media > > > > > > streams that are no longer wanted to disabled or inactive. > > > > > > Because this is persistent recording, the RS would typically > > > > > > remain in place awaiting other recordable CSs. > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > > > > > Other places in the document will also need some changes, > > > > > > but I would like first to see if we can get agreement on the > > > > > > general principle and on inclusion of this scenario in section > > 4. > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > John Elwell > > > > > > > Tel: +44 1908 817801 (office and mobile) > > > > > > > Email: john.elwell@siemens-enterprise.com > > > > > > > http://www.siemens-enterprise.com/uk/ > > > > > > > > > > > > > > Siemens Enterprise Communications Limited. > > > > > > > Registered office: Brickhill Street, Willen Lake, Milton > > > > > > Keynes, MK15 0DJ. > > > > > > > Registered No: 5903714, England. > > > > > > > > > > > > > > Siemens Enterprise Communications Limited is a Trademark > > > > > > Licensee of Siemens AG. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > siprec mailing list > > > > > > > siprec@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > siprec mailing list > > > > > > siprec@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > _______________________________________________ > > > > > siprec mailing list > > > > > siprec@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > From pkyzivat@alum.mit.edu Sat Aug 27 06:54:13 2011 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 5072021F8AED for ; Sat, 27 Aug 2011 06:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 P8yOvL-UnCfP for ; Sat, 27 Aug 2011 06:54:12 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id 0220D21F8AAA for ; Sat, 27 Aug 2011 06:54:11 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta14.westchester.pa.mail.comcast.net with comcast id RRnk1h0041ZXKqc5ERvXr5; Sat, 27 Aug 2011 13:55:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta21.westchester.pa.mail.comcast.net with comcast id RRvV1h00A0tdiYw3hRvVcm; Sat, 27 Aug 2011 13:55:30 +0000 Message-ID: <4E58F751.4030208@alum.mit.edu> Date: Sat, 27 Aug 2011 09:55:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <4E53BF55.3010309@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] SRS-initiated INVITE X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 13:54:13 -0000 On 8/26/11 5:16 PM, Charles Eckel (eckelcu) wrote: >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> Sent: Thursday, August 25, 2011 12:50 AM >> To: Charles Eckel (eckelcu); Paul Kyzivat; siprec@ietf.org >> Subject: RE: [siprec] SRS-initiated INVITE >> >> Charles, >> >> But I still don't understand your earlier statement "The SRC could > initiate the CS INVITE in this >> case." >> >> I agree that an SRS could be asked, but some means outside SIPREC, to > establish recording for a >> conference, and given some sort of reference for the conference, could > initiate the INVITE to the SRC >> (collocated with the conference focus). >> >> The question is how to get the INVITE from SRS to SRC to identify the > conference to be recorded. >> Should that just be implicit in the Request-URI (the way Request-URIs > are constructed would be outside >> the scope of SIPREC), or do we need something explicit? > > The Request URI could be used, but if others agree this is a worthwhile > use case, I think it would be more appropriate to define something > explicit. Taking this to the extreme, the explicit information could be > in the form of metadata from the SRS to the SRC, providing as much > information about the intended recording as the SRS knows. ISTM that this is a slippery slope - there are many possibilities for how one might want to specify what to record. I can foresee desires much like what came out in Martini for bulk registrations. I would be happy to leave this out of scope for now. Thanks, Paul > Cheers, > Charles > >> I think I agree that neither Join nor Target-Dialog header fields have > quite the right semantics for >> this, so if we need an explicit means of identifying the existing > conference we would have to invent a >> new mechanism. >> >> John (as individual) >> >> >> >>> -----Original Message----- >>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>> Sent: 24 August 2011 21:29 >>> To: Elwell, John; Paul Kyzivat; siprec@ietf.org >>> Subject: RE: [siprec] SRS-initiated INVITE >>> >>> Please see inline. >>> >>>> -----Original Message----- >>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>> Sent: Wednesday, August 24, 2011 12:49 AM >>>> To: Charles Eckel (eckelcu); Paul Kyzivat; siprec@ietf.org >>>> Subject: RE: [siprec] SRS-initiated INVITE >>>> >>>> Charles,, >>>> >>>>> -----Original Message----- >>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>>>> Sent: 23 August 2011 22:06 >>>>> To: Elwell, John; Paul Kyzivat; siprec@ietf.org >>>>> Subject: RE: [siprec] SRS-initiated INVITE >>>>> >>>>> Hi John, >>>>> >>>>> I was envisioning a use case in which the INVITE from the SRS >>>>> to the SRC >>>>> contains a Request-URI for a call that is to be joined for the >>> purpose >>>>> of recording (e.g. a conference call). The SRS may include >>>>> SDP as well. >>>> [JRE] So this would be a different use case, for recording only a >>> specific call. Did you envisage >>>> using the Join or Target-Dialog header field to identify the CS >>> dialog? >>>> >>>>> The SRC could initiate the CS INVITE in this case. >>> >>> I do not think either of those is really appropriate for this. >>> >>>> [JRE] Not sure I understand this. I had assumed, from what >>> you said at >>> the start, that the purpose >>>> would be to record a CS already in progress, so the initial >>> CS INVITE >>> would be history. I can't >>>> imagine why the SRS would want the SRC to establish a CS for the >>> purpose of recording. >>>> >>>> John (as individual) >>> >>> Take the case of a conference call is that is not being recorded. At >>> some point in time, someone decides they want to start recording the >>> conference. This could be done by a SIP UA that is >>> participating in the >>> conference, or by the focus of the conference, acting as or >>> interacting >>> with the SRC. This is already covered by our use cases. But it could >>> also be accomplished using some mechanism outside the scope of the >>> SIPREC that asks the SRS to record the conference. While the >>> trigger is >>> outside the scope of SIPREC, the way the SRS initiates the RS >>> is what I >>> think could be considered in scope for SIPREC. >>> >>> Cheers, >>> Charles >>> >>> >>>> >>>>> I'd like to hear what others think about making your proposal > more >>>>> generic to accommodate that as well. >>>>> >>>>> Cheers, >>>>> Charles >>>>> >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org] On >>>>> Behalf Of Elwell, John >>>>>> Sent: Tuesday, August 23, 2011 12:51 PM >>>>>> To: Paul Kyzivat; siprec@ietf.org >>>>>> Subject: Re: [siprec] SRS-initiated INVITE >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: siprec-bounces@ietf.org >>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>>>> Sent: 23 August 2011 15:55 >>>>>>> To: siprec@ietf.org >>>>>>> Subject: Re: [siprec] SRS-initiated INVITE >>>>>>> >>>>>>> IIUC, the essential feature of this flow is that the R-URI >>>>>>> from SRS to >>>>>>> SRC in some way encodes the criteria for what calls the SRC >>>>>>> should record. >>>>>>> >>>>>>> I guess you are assuming that the manner of that encoding is >>>>>>> unstandardized, and hence requires a side agreement between >>>>>>> the SRC and >>>>>>> SRS. Or else it requires that the SRS be configurable to >>>>>>> establish an RS >>>>>>> to an arbitrary URI, and that the administrator is aware of >>>>>>> the specific >>>>>>> URI encoding required by the SRC to achieve the >>> intended effect. >>>>>>> >>>>>>> While that is a bit of a stretch, I don't have any > particular >>>>> problem >>>>>>> with including such an example. But this doesn't ensure >>>>> that any SRC >>>>>>> actually has this capability. >>>>>> [JRE] Quite so. But if the SRC has a URI that can be used >>>>> and the SRS >>>>> is configured with that URI, it >>>>>> should work. >>>>>> >>>>>> John >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>> On 8/23/11 7:03 AM, Elwell, John wrote: >>>>>>>> (as individual) >>>>>>>> >>>>>>>> During the IETF 81 session, Andy and I agreed to propose >>>>>>> some text for the protocol document to cover the case of >>>>>>> SRS-initiated INVITE in more detail. This is our proposal: >>>>>>>> >>>>>>>> ======================= >>>>>>>> The following is a sample call flow that shows the SRS >>>>>>> establishing a recording session towards the SRC. The most >>>>>>> likely application of this is for persistent recording, > where >>>>>>> the SRS does not need to have prior knowledge of particular >>>>>>> CSs that need to be recorded but simply requires to record >>>>>>> all CSs with certain characteristics (e.g., involving a >>>>>>> particular user). Also it is more likely to arise when the >>>>>>> SRC is located at a B2BUA, rather than at a UA, and > therefore >>>>>>> the SRS does not need to identify a particular UA as the >>>>>>> target of the INVITE request. >>>>>>>> >>>>>>>> >>>>>>>> UA A SRC UA B >>>>>>> SRS >>>>>>>> | | (1) RS INVITE without SDP >>>>> | >>>>>>>> | >>>>> |<---------------------------------------------| >>>>>>>> | | (2) OK with SDP >>>>> | >>>>>>>> | >>>>> |--------------------------------------------->| >>>>>>>> | | (3) ACK with SDP >>>>> | >>>>>>>> | >>>>> |<---------------------------------------------| >>>>>>>> |(4)CS INVITE | | >>>>> | >>>>>>>> |------------->| | >>>>> | >>>>>>>> | |(5)CS INVITE | >>>>> | >>>>>>>> | |---------------------->| >>>>> | >>>>>>>> | | (6)OK | >>>>> | >>>>>>>> | |<----------------------| >>>>> | >>>>>>>> | (7)OK | | >>>>> | >>>>>>>> |<-------------| | >>>>> | >>>>>>>> | |(8)RS UPDATE with SDP and metadata >>>>> | >>>>>>>> | >>>>> |--------------------------------------------->| >>>>>>>> | | (9)OK with SDP >>>>> | >>>>>>>> | >>>>> |<---------------------------------------------| >>>>>>>> |(10)CS RTP | | >>>>> | >>>>>>>> |=============>|======================>| >>>>> | >>>>>>>> |<=============|<======================| >>>>> | >>>>>>>> | |(11)RS RTP | >>>>> | >>>>>>>> | >>>>> |=============================================>| >>>>>>>> | >>>>> |=============================================>| >>>>>>>> |(12)CS BYE | | >>>>> | >>>>>>>> |------------->| | >>>>> | >>>>>>>> | |(13)CS BYE | >>>>> | >>>>>>>> | |---------------------->| >>>>> | >>>>>>>> | | (14) CS OK | >>>>> | >>>>>>>> | |<----------------------| >>>>> | >>>>>>>> | (15)OK | | >>>>> | >>>>>>>> |<-------------| | >>>>> | >>>>>>>> | |(16)UPDATE with SDP and metadata >>>>>>> | | >>>>>>>> | >>>>> |--------------------------------------------->| >>>>>>>> | | (17)OK with SDP >>>>> | >>>>>>>> | >>>>> |<---------------------------------------------| >>>>>>>> | | | >>>>> | >>>>>>>> >>>>>>>> Figure 2: Persistent Recording Call Flow, RS >>>>>>> Established by SRS >>>>>>>> >>>>>>>> The initial INVITE request for establishing the RS (1) has >>>>>>> a Request-URI that identifies the SRC and instructs the SRC >>>>>>> what to record (e.g., all CSs involving a particular user). >>>>>>> The SDP offer from the SRC (2) might have no media or might >>>>>>> establish inactive media in anticipation of future >>> requirements. >>>>>>>> >>>>>>>> The first UPDATE request (8) occurs on establishment of a >>>>>>> recordable CS. It includes metadata describing the CS and, > if >>>>>>> necessary, includes a new SDP offer to establish or modify >>>>>>> media streams needed for recording that CS. >>>>>>>> >>>>>>>> The second UPDATE request (16) occurs on termination of a >>>>>>> recordable CS. It includes metadata indicating termination > of >>>>>>> the CS and might include a new SDP offer changing media >>>>>>> streams that are no longer wanted to disabled or inactive. >>>>>>> Because this is persistent recording, the RS would typically >>>>>>> remain in place awaiting other recordable CSs. >>>>>>>> ================================= >>>>>>>> >>>>>>>> Other places in the document will also need some changes, >>>>>>> but I would like first to see if we can get agreement on the >>>>>>> general principle and on inclusion of this scenario in > section >>> 4. >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>> >>>>>>>> John Elwell >>>>>>>> Tel: +44 1908 817801 (office and mobile) >>>>>>>> Email: john.elwell@siemens-enterprise.com >>>>>>>> http://www.siemens-enterprise.com/uk/ >>>>>>>> >>>>>>>> Siemens Enterprise Communications Limited. >>>>>>>> Registered office: Brickhill Street, Willen Lake, Milton >>>>>>> Keynes, MK15 0DJ. >>>>>>>> Registered No: 5903714, England. >>>>>>>> >>>>>>>> Siemens Enterprise Communications Limited is a Trademark >>>>>>> Licensee of Siemens AG. >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> siprec mailing list >>>>>>>> siprec@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> siprec mailing list >>>>>>> siprec@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>> >>>>>> _______________________________________________ >>>>>> siprec mailing list >>>>>> siprec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>> > From john.elwell@siemens-enterprise.com Tue Aug 30 01:17:11 2011 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 ADD6B21F8B8E for ; Tue, 30 Aug 2011 01:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.929 X-Spam-Level: X-Spam-Status: No, score=-101.929 tagged_above=-999 required=5 tests=[AWL=-1.744, BAYES_40=-0.185, 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 9ttZX-mlUWg2 for ; Tue, 30 Aug 2011 01:17:11 -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 1B9EF21F8B8C for ; Tue, 30 Aug 2011 01:17:11 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 9F2651EB843C for ; Tue, 30 Aug 2011 10:18:36 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 30 Aug 2011 10:18:36 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Tue, 30 Aug 2011 10:18:35 +0200 Thread-Topic: Question on start-time Thread-Index: Acxm7Wl+WcVmVDEwTle2VOQtIuY9Kw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Question on start-time 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, 30 Aug 2011 08:17:11 -0000 The start-time child element is optional in elements like participant, sess= ion, etc.. If it is included in one version of the metadata and then omitte= d in the next version, what does this mean? Once added, does it need to be = included in each iteration of the metadata until that element has been dele= ted (stop-time added), or can it be omitted? What assumption should the SRS= make in this case? Should it assume the value is unchanged? John (as individual) John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. From rmohanr@cisco.com Tue Aug 30 02:31:51 2011 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 D5B6D21F8BCD for ; Tue, 30 Aug 2011 02:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.09 X-Spam-Level: X-Spam-Status: No, score=-6.09 tagged_above=-999 required=5 tests=[AWL=-3.491, 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 TGu2iYgszCID for ; Tue, 30 Aug 2011 02:31:51 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id F322921F8AB0 for ; Tue, 30 Aug 2011 02:31:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=2452; q=dns/txt; s=iport; t=1314696798; x=1315906398; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=DDg5OcqnjcPHnuF0K+4mNSIExi0+u1/0pHTIy9DFUxc=; b=U6fik6ifkTsrBsXoUpy3CP2uFouA3DwBbRt0436KIG7JHuqmwO32S3it RGrsm+lcnBtbvkReOk1F+CjYCNAW4XPebC7qjW1HWZnIjA9E5U5/YuwIw H7irAAI9D0EMiVjObRhs0vm11BVZmygvUnV5wNYTX1XgKHXFFCmii1nAv U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkAALqtXE6rRDoI/2dsb2JhbABCmDCPYneBQAEBAQECAQEBAQ8BHQo0FwQCAQgRBAEBCwYXAQYBJh8JCAEBBAEKCAgah1AElxMBn1OFbWAEh2SQV4t2 X-IronPort-AV: E=Sophos;i="4.68,301,1312156800"; d="scan'208";a="17722858" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-5.cisco.com with ESMTP; 30 Aug 2011 09:33:17 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7U9WW7k015028; Tue, 30 Aug 2011 09:33:17 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Aug 2011 15:02:47 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Aug 2011 15:02:46 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD077D8405@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Question on start-time Thread-Index: Acxm7Wl+WcVmVDEwTle2VOQtIuY9KwACF/Yg References: From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , X-OriginalArrivalTime: 30 Aug 2011 09:32:47.0524 (UTC) FILETIME=[C7667E40:01CC66F7] Subject: Re: [siprec] Question on start-time 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, 30 Aug 2011 09:31:51 -0000 Hi John, Please see inline > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Tuesday, August 30, 2011 1:49 PM > To: siprec@ietf.org > Subject: [siprec] Question on start-time >=20 > The start-time child element is optional in elements like participant, > session, etc.. If it is included in one version of the metadata and > then omitted in the next version, what does this mean? Once added, does > it need to be included in each iteration of the metadata until that > element has been deleted (stop-time added), or can it be omitted? What > assumption should the SRS make in this case? Should it assume the value > is unchanged? Start(associate-time) is the time at which an element is associated/started. For e.g, in case of a participant associate-time is the time at which a participant associates to a session. Dis-associate time is the time a participant disassociates from a session. Note that the participant may again associate to the same CS during its lifetime as we agreed in IETF81. For the above an SRC may send a snapshot metadata having associate-time for participant at Instance T0. Subsequent metadata snapshots(partial updates) from SRC to SRS ( say sent at time T1, T2) does not have the associate-time for the participant.=20 Meanwhile if the SRS requests for a complete snapshot at some point ( say T3) from SRC, that snapshot from SRC may include the associate-time in case the SRC has saved it. Eventually when the participant disassociates( at time T4) from the CS metadata snapshot from SRC to SRS will have a disassociate-time. So to summarize the associate-time need not be included every time. Also there may be implementations where an SRC may not send times at all (as they are optional).=20 Regards, Ram >=20 > John (as individual) >=20 > John Elwell > Tel: +44 1908 817801 (office and mobile) > Email: john.elwell@siemens-enterprise.com > http://www.siemens-enterprise.com/uk/ >=20 > Siemens Enterprise Communications Limited. > Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 > 0DJ. > Registered No: 5903714, England. >=20 > Siemens Enterprise Communications Limited is a Trademark Licensee of > Siemens AG. > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Tue Aug 30 05:08:50 2011 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 0D7A221F8C26 for ; Tue, 30 Aug 2011 05:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.124 X-Spam-Level: X-Spam-Status: No, score=-103.124 tagged_above=-999 required=5 tests=[AWL=-0.525, 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 SG+FWhqa3zFB for ; Tue, 30 Aug 2011 05:08:49 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 0F61921F8C10 for ; Tue, 30 Aug 2011 05:08:48 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 7CED223F046D; Tue, 30 Aug 2011 14:09:59 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 30 Aug 2011 14:09:59 +0200 From: "Elwell, John" To: "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Date: Tue, 30 Aug 2011 14:09:57 +0200 Thread-Topic: [siprec] Question on start-time Thread-Index: Acxm7Wl+WcVmVDEwTle2VOQtIuY9KwACF/YgAAXpdJA= Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD077D8405@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD077D8405@XMB-BGL-417.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Question on start-time 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, 30 Aug 2011 12:08:50 -0000 If this is a common understanding, perhaps we need some general statement i= n the draft on how to interpret missing child elements of elements (e.g., s= tart-time) that are free-standing (i.e., participant, group, session, strea= m). John=20 > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 > Sent: 30 August 2011 10:33 > To: Elwell, John; siprec@ietf.org > Subject: RE: [siprec] Question on start-time >=20 > Hi John, >=20 > Please see inline >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > > Sent: Tuesday, August 30, 2011 1:49 PM > > To: siprec@ietf.org > > Subject: [siprec] Question on start-time > >=20 > > The start-time child element is optional in elements like=20 > participant, > > session, etc.. If it is included in one version of the metadata and > > then omitted in the next version, what does this mean? Once added, > does > > it need to be included in each iteration of the metadata until that > > element has been deleted (stop-time added), or can it be=20 > omitted? What > > assumption should the SRS make in this case? Should it assume the > value > > is unchanged? >=20 > Start(associate-time) is the time at which an element is > associated/started. For e.g, in case of a participant=20 > associate-time is > the time at which a participant associates to a session. Dis-associate > time is the time a participant disassociates from a session. Note that > the participant may again associate to the same CS during its lifetime > as we agreed in IETF81. >=20 > For the above an SRC may send a snapshot metadata having=20 > associate-time > for participant at Instance T0. Subsequent metadata snapshots(partial > updates) from SRC to SRS ( say sent at time T1, T2) does not have the > associate-time for the participant.=20 > Meanwhile if the SRS requests for a complete snapshot at some point ( > say T3) from SRC, that snapshot from SRC may include the=20 > associate-time > in case the SRC has saved it. > Eventually when the participant disassociates( at time T4) from the CS > metadata snapshot from SRC to SRS will have a disassociate-time. >=20 > So to summarize the associate-time need not be included every time. > Also there may be implementations where an SRC may not send=20 > times at all > (as they are optional).=20 >=20 > Regards, > Ram >=20 > >=20 > > John (as individual) > >=20 > > John Elwell > > Tel: +44 1908 817801 (office and mobile) > > Email: john.elwell@siemens-enterprise.com > > http://www.siemens-enterprise.com/uk/ > >=20 > > Siemens Enterprise Communications Limited. > > Registered office: Brickhill Street, Willen Lake, Milton=20 > Keynes, MK15 > > 0DJ. > > Registered No: 5903714, England. > >=20 > > Siemens Enterprise Communications Limited is a Trademark Licensee of > > Siemens AG. > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > = From rmohanr@cisco.com Tue Aug 30 06:24:34 2011 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 E5B9621F8BCD for ; Tue, 30 Aug 2011 06:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.019 X-Spam-Level: X-Spam-Status: No, score=-10.019 tagged_above=-999 required=5 tests=[AWL=0.580, 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 RB9KPoTw5C6s for ; Tue, 30 Aug 2011 06:24:33 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 630F921F8BD8 for ; Tue, 30 Aug 2011 06:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=3815; q=dns/txt; s=iport; t=1314710760; x=1315920360; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=iafpZRc6wJav93fvm2pvM14VDQzsUimapcpB6S/ZrcY=; b=RfxVTThLaEy/8GrqWElGJoI/PzbVC2WhD0Od5aVJ7JVb3kxCpKROL8E6 rNw3Km5NTjLA0MdRtn6pIds8Z87nh3U/wkQUzDSpHjtQGEGjwZwcwISa6 HY7RCqv3fSPZCXcSaN3ClAxvBpSJtx6bA/6wdXx91ANCgGdPorwzRxBQX k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkAAMPkXE5Io8UR/2dsb2JhbABCmDKPY3eBQAEBAQECAQEBAQ8BHQo0EAcEAgEIEQQBAQsGFwEGASYfCQgBAQQBCggIGodQBJkyAZ9JhW1gBIdkkFeLdg X-IronPort-AV: E=Sophos;i="4.68,302,1312156800"; d="scan'208";a="113216041" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 30 Aug 2011 13:25:48 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7UDPlAe008188; Tue, 30 Aug 2011 13:25:47 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Aug 2011 18:55:47 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Aug 2011 18:55:45 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD077D84EF@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Question on start-time Thread-Index: Acxm7Wl+WcVmVDEwTle2VOQtIuY9KwACF/YgAAXpdJAAAqTC0A== References: <35BCE99A477D6A4986FB2216D8CF2CFD077D8405@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , X-OriginalArrivalTime: 30 Aug 2011 13:25:47.0828 (UTC) FILETIME=[544F9740:01CC6718] Subject: Re: [siprec] Question on start-time 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, 30 Aug 2011 13:24:34 -0000 Sure. I will try to add some text in the draft to make it explicit. Do we want the text to be added in ver 04 itself ? or Do we need more discussions ? While I was thinking of start/stop (or associate/disassociate) for different elements I have a question regarding times for session time. I will start a new thread for the same. Regards, Ram > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Tuesday, August 30, 2011 5:40 PM > To: Ram Mohan R (rmohanr); siprec@ietf.org > Subject: RE: [siprec] Question on start-time >=20 > If this is a common understanding, perhaps we need some general > statement in the draft on how to interpret missing child elements of > elements (e.g., start-time) that are free-standing (i.e., participant, > group, session, stream). >=20 > John >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > Sent: 30 August 2011 10:33 > > To: Elwell, John; siprec@ietf.org > > Subject: RE: [siprec] Question on start-time > > > > Hi John, > > > > Please see inline > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Elwell, John > > > Sent: Tuesday, August 30, 2011 1:49 PM > > > To: siprec@ietf.org > > > Subject: [siprec] Question on start-time > > > > > > The start-time child element is optional in elements like > > participant, > > > session, etc.. If it is included in one version of the metadata and > > > then omitted in the next version, what does this mean? Once added, > > does > > > it need to be included in each iteration of the metadata until that > > > element has been deleted (stop-time added), or can it be > > omitted? What > > > assumption should the SRS make in this case? Should it assume the > > value > > > is unchanged? > > > > Start(associate-time) is the time at which an element is > > associated/started. For e.g, in case of a participant > > associate-time is > > the time at which a participant associates to a session. Dis- > associate > > time is the time a participant disassociates from a session. Note > that > > the participant may again associate to the same CS during its > lifetime > > as we agreed in IETF81. > > > > For the above an SRC may send a snapshot metadata having > > associate-time > > for participant at Instance T0. Subsequent metadata snapshots(partial > > updates) from SRC to SRS ( say sent at time T1, T2) does not have the > > associate-time for the participant. > > Meanwhile if the SRS requests for a complete snapshot at some point ( > > say T3) from SRC, that snapshot from SRC may include the > > associate-time > > in case the SRC has saved it. > > Eventually when the participant disassociates( at time T4) from the > CS > > metadata snapshot from SRC to SRS will have a disassociate-time. > > > > So to summarize the associate-time need not be included every time. > > Also there may be implementations where an SRC may not send > > times at all > > (as they are optional). > > > > Regards, > > Ram > > > > > > > > John (as individual) > > > > > > John Elwell > > > Tel: +44 1908 817801 (office and mobile) > > > Email: john.elwell@siemens-enterprise.com > > > http://www.siemens-enterprise.com/uk/ > > > > > > Siemens Enterprise Communications Limited. > > > Registered office: Brickhill Street, Willen Lake, Milton > > Keynes, MK15 > > > 0DJ. > > > Registered No: 5903714, England. > > > > > > Siemens Enterprise Communications Limited is a Trademark Licensee > of > > > Siemens AG. > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > From rmohanr@cisco.com Tue Aug 30 06:59:04 2011 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 0E83521F8C6E for ; Tue, 30 Aug 2011 06:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.03 X-Spam-Level: X-Spam-Status: No, score=-10.03 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 xI+v2nL+xtiO for ; Tue, 30 Aug 2011 06:59:02 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C810721F8C6C for ; Tue, 30 Aug 2011 06:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=9976; q=dns/txt; s=iport; t=1314712829; x=1315922429; h=mime-version:subject:date:message-id:from:to; bh=hwg8G3YCvJZnd0EnDFJof5T58u/mZ0qPyizse+fA/ds=; b=GSeNYbK8boT9pR3ZRWGAfru7JMtaDNCU6xT0UZg7JIehfpOZAVtX0bh0 BYAWOSVnT9cyeiM37Lgk4L/4Kf1FLMCAQD6ieSBQF3xwv2e6x2T5BFChy Q8zlZcgYwybebBhCVfpT9Ni4JqI9HDn+jag7YVWBz89kIyFCmgxF5yJVO Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKnrXE5Io8UQ/2dsb2JhbABDgk2lSHeBQgEBAxIBCREDWwEqBhgHVwEECxAan1iBIwGfSIVtYASHZJBXi3Y X-IronPort-AV: E=Sophos;i="4.68,302,1312156800"; d="scan'208,217";a="113222313" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 30 Aug 2011 14:00:22 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7UE0LQY025524 for ; Tue, 30 Aug 2011 14:00:21 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Aug 2011 19:30:22 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC671D.28B977B4" Date: Tue, 30 Aug 2011 19:30:20 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD077D8511@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: start/stop time for Communication Session object Thread-Index: AcxnHSf0B45izIIgTP6nrv8gP3GPsQ== From: "Ram Mohan R (rmohanr)" To: X-OriginalArrivalTime: 30 Aug 2011 14:00:22.0392 (UTC) FILETIME=[28D8EF80:01CC671D] Subject: [siprec] start/stop time for Communication Session object 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, 30 Aug 2011 13:59:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC671D.28B977B4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As per draft-ietf-siprec-metadata-03 start/stop time for CS is defined as Start Time - This optional attribute represents CS start time End Time - This optional attribute represents CS end time =20 Is this sufficient ?=20 =20 OR should we change this to associate/disassociate and have the meaning and scope as: =20 Associate-time - The optional attribute represents the time a CS is associated with a RS Disassociate-time- This optional attributes represents the time a CS disassociates from a RS. =20 Associate/Disassociate times gives some more flexibility as explained in below example over Start/End time but I am not sure if there is a desire to have it and so would welcome comments.=20 =20 e.g. An SRC starts recording a CS1 as part of RS1. For some reason the recording of CS1 is stopped for a while.=20 After some time when SRC wants to resume recording of CS1. There are different possibilities: 1) SRC may have disconnected RS1. So, SRC may setup RS2 and continue to record CS1. In this case SRC after the CS1 finishes will indicate End Time in RS2. 2) SRC will not disconnect RS1 (as it is persistent) and continues to record CS1 as part of RS1 itself.=20 3) SRC will not disconnect RS1(persistent). But will continue to record CS1 as part of another RS (RS2).=20 2) SRC does not setup any more Recording Session for this CS (CS1). End Time for CS will never be indicated. Since End Time is optional, this is still fine. =20 If we can use associate/disassociate time, it gives more flexibility as we can indicate times each time CS1 is associated/disassociated to a RS for each of the above cases. =20 Note that I am happy to retain the current text/scope as it is, but I just want to clearly articulate the scope of start/stop time of CS and make sure its sufficient Regards, Ram =20 ------_=_NextPart_001_01CC671D.28B977B4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As per = draft-ietf-siprec-metadata-03 start/stop time for CS is defined = as

   Start Time - This = optional attribute represents CS start time

  End Time - This optional attribute = represents CS end time

 

Is this = sufficient ?

 

OR should we change this to associate/disassociate and = have the meaning and scope as:

 

Associate-time – The optional attribute = represents the time a CS is associated with a RS

Disassociate-time- This optional attributes represents = the time a CS disassociates from a RS.

 

Associate/Disassociate times gives some more =  flexibility as explained in below example over Start/End time but = I am not sure if there is a desire to have it and so would welcome = comments.

 

e.g. An SRC starts recording a CS1 as part of RS1. =  For some reason the recording of CS1 is stopped for a while. =

After some time when SRC wants to = resume recording of CS1. There are different = possibilities:

1) SRC may have = disconnected RS1. So, SRC may setup RS2 and continue to record CS1. In = this case SRC after the CS1 finishes will indicate End Time in = RS2.

2) SRC will not disconnect RS1 = (as it is persistent) and continues to record CS1 as part of RS1 itself. =

3) SRC will not disconnect = RS1(persistent). But will continue to record CS1 as part of another RS = (RS2).

2) SRC does not setup any = more Recording Session for this CS (CS1).  End Time for CS will = never be indicated. Since End Time is optional, this is still = fine.

 

If we can use associate/disassociate time, it gives = more flexibility as we can indicate times each time CS1 is = associated/disassociated to a RS for each of the above = cases.

 

Note that I am happy to retain the current = text/scope  as it is, but I just want to clearly articulate the = scope of start/stop time of CS and make sure its = sufficient

Regards,

Ram

 

------_=_NextPart_001_01CC671D.28B977B4--